litmus-rt.git/drivers/firewire, branch master The LITMUS^RT kernel. Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 2015-03-04T02:16:48+00:00 David S. Miller davem@davemloft.net 2015-03-04T02:16:48+00:00 71a83a6db6138b9d41d8a0b6b91cb59f6dc4742c Conflicts: drivers/net/ethernet/rocker/rocker.c The rocker commit was two overlapping changes, one to rename the ->vport member to ->pport, and another making the bitmask expression use '1ULL' instead of plain '1'. Signed-off-by: David S. Miller <davem@davemloft.net> 
Conflicts:
	drivers/net/ethernet/rocker/rocker.c

The rocker commit was two overlapping changes, one to rename
the ->vport member to ->pport, and another making the bitmask
expression use '1ULL' instead of plain '1'.

Signed-off-by: David S. Miller <davem@davemloft.net>
net: Kill dev_rebuild_header 2015-03-02T21:43:41+00:00 Eric W. Biederman ebiederm@xmission.com 2015-03-02T06:11:09+00:00 d476059e77d1af48453a58f9de1e36f2eaff6450 Now that there are no more users kill dev_rebuild_header and all of it's implementations. This is long overdue. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
Now that there are no more users kill dev_rebuild_header and all of it's
implementations.

This is long overdue.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
firewire: core: use correct vendor/model IDs 2015-02-02T20:56:03+00:00 Clemens Ladisch clemens@ladisch.de 2015-01-28T20:04:48+00:00 d71e6a11737f4b3d857425a1d6f893231cbd1296 The kernel was using the vendor ID 0xd00d1e, which was inherited from the old ieee1394 driver stack. However, this ID was not registered, and invalid. Instead, use the vendor/model IDs that are now officially assigned to the kernel: https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments [stefanr: - The vendor ID 001f11 is Openmoko, Inc.'s identifier, registered at IEEE Registration Authority. - The range of model IDs 023900...0239ff are the Linux kernel 1394 subsystem's identifiers, registered at Openmoko. - Model ID 023901 is picked by the subsystem developers as firewire-core's model ID.] Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 
The kernel was using the vendor ID 0xd00d1e, which was inherited from
the old ieee1394 driver stack.  However, this ID was not registered, and
invalid.

Instead, use the vendor/model IDs that are now officially assigned to
the kernel:
https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments

[stefanr:
  - The vendor ID 001f11 is Openmoko, Inc.'s identifier, registered at
    IEEE Registration Authority.
  - The range of model IDs 023900...0239ff are the Linux kernel 1394
    subsystem's identifiers, registered at Openmoko.
  - Model ID 023901 is picked by the subsystem developers as
    firewire-core's model ID.]

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: sbp2: remove redundant check for bidi command 2015-01-31T14:27:40+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2015-01-23T14:05:13+00:00 1f95f8c9fddb14ec0c5b2d49f691b9c2aee7b9b9 [Bart van Asche:] SCSI core never sets cmd->sc_data_direction to DMA_BIDIRECTIONAL; scsi_bidi_cmnd(cmd) should be used instead to test for a bidirectional command. [Christoph Hellwig:] Bidirectional commands won't ever be queued anyway, unless a LLD or transport driver sets QUEUE_FLAG_BIDI. So, simply remove the respective queuecommand check in the SBP-2 transport driver. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 
[Bart van Asche:]  SCSI core never sets cmd->sc_data_direction to
DMA_BIDIRECTIONAL; scsi_bidi_cmnd(cmd) should be used instead to
test for a bidirectional command.

[Christoph Hellwig:]  Bidirectional commands won't ever be queued
anyway, unless a LLD or transport driver sets QUEUE_FLAG_BIDI.

So, simply remove the respective queuecommand check in the SBP-2
transport driver.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: ohci: Remove unused function 2015-01-22T10:08:52+00:00 Rickard Strandqvist rickard_strandqvist@spectrumdigital.se 2015-01-02T21:02:43+00:00 b625a825955ede39047e821f4b69f36cf042b952 Remove the function ar_prev_buffer_index() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 
Remove the function ar_prev_buffer_index() that is not used anywhere.

This was partially found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: sbp2: replace card lock by target lock 2014-12-10T19:53:21+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2014-03-03T22:23:51+00:00 d737d7da8e7e931360282199341f44ac0803c837 firewire-core uses fw_card.lock to protect topology data and transaction data. firewire-sbp2 uses fw_card.lock for entirely unrelated purposes. Introduce a sbp2_target.lock to firewire-sbp2 and replace all fw_card.lock uses in the driver. fw_card.lock is now entirely private to firewire-core. This has no immediate advantage apart from making it clear in the code that firewire-sbp2 does not interact with the core via the core lock. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 
firewire-core uses fw_card.lock to protect topology data and transaction
data.  firewire-sbp2 uses fw_card.lock for entirely unrelated purposes.

Introduce a sbp2_target.lock to firewire-sbp2 and replace all
fw_card.lock uses in the driver.  fw_card.lock is now entirely private
to firewire-core.  This has no immediate advantage apart from making it
clear in the code that firewire-sbp2 does not interact with the core
via the core lock.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: sbp2: replace some spin_lock_irqsave by spin_lock_irq 2014-12-10T19:53:20+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2014-03-03T22:23:22+00:00 8e045a31e7c0536e4deb750b37c919fadcb44aa3 Users of card->lock Calling context ------------------------------------------------------------------------ sbp2_status_write AR-req handler, tasklet complete_transaction AR-resp or AT-req handler, tasklet sbp2_send_orb among else scsi host .queuecommand, which may be called in some sort of atomic context sbp2_cancel_orbs sbp2_send_management_orb/ sbp2_{login,reconnect,remove}, worklet or process sbp2_scsi_abort, scsi eh thread sbp2_allow_block sbp2_login, worklet sbp2_conditionally_block among else complete_command_orb, tasklet sbp2_conditionally_unblock sbp2_{login,reconnect}, worklet sbp2_unblock sbp2_{login,remove}, worklet or process Drop the IRQ flags saving from sbp2_cancel_orbs, sbp2_conditionally_unblock, and sbp2_unblock. It was already omitted in sbp2_allow_block. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 
Users of card->lock        Calling context
------------------------------------------------------------------------
sbp2_status_write          AR-req handler, tasklet
complete_transaction       AR-resp or AT-req handler, tasklet
sbp2_send_orb              among else scsi host .queuecommand, which may
                           be called in some sort of atomic context
sbp2_cancel_orbs           sbp2_send_management_orb/
                               sbp2_{login,reconnect,remove},
                               worklet or process
                           sbp2_scsi_abort, scsi eh thread
sbp2_allow_block           sbp2_login, worklet
sbp2_conditionally_block   among else complete_command_orb, tasklet
sbp2_conditionally_unblock sbp2_{login,reconnect}, worklet
sbp2_unblock               sbp2_{login,remove}, worklet or process

Drop the IRQ flags saving from sbp2_cancel_orbs,
sbp2_conditionally_unblock, and sbp2_unblock.
It was already omitted in sbp2_allow_block.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: sbp2: protect a reference counter properly 2014-12-10T19:53:20+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2014-03-03T22:22:35+00:00 0765cbd3be699b4a72db67069247d514f06a1e4f The assertion in the comment in sbp2_allow_block() is no longer true. Or maybe it never was true. At least now, the sole caller of sbp2_allow_block(), sbp2_login, can run concurrently to one of sbp2_unblock()'s callers, sbp2_remove. sbp2_login is performed by sbp2_logical_unit.work. sbp2_remove is performed by fw_device.work. sbp2_remove cancels sbp2_logical_unit.work, but only after it called sbp2_unblock. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 
The assertion in the comment in sbp2_allow_block() is no longer true.
Or maybe it never was true.  At least now, the sole caller of
sbp2_allow_block(), sbp2_login, can run concurrently to one of
sbp2_unblock()'s callers, sbp2_remove.

sbp2_login is performed by sbp2_logical_unit.work.
sbp2_remove is performed by fw_device.work.
sbp2_remove cancels sbp2_logical_unit.work, but only after it called
sbp2_unblock.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
firewire: core: document fw_csr_string's truncation of long strings 2014-12-10T19:53:02+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2014-11-19T10:52:00+00:00 0238507b951857360461b0635111e7376ffd44d1 fw_csr_string() truncates and terminates target strings like strlcpy() does. Unlike strlcpy(), it returns the target strlen, not the source strlen, hence users of fw_csr_string() are unable to detect truncation. Point this behavior out in the kerneldoc comment. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> 
fw_csr_string() truncates and terminates target strings like strlcpy()
does.  Unlike strlcpy(), it returns the target strlen, not the source
strlen, hence users of fw_csr_string() are unable to detect truncation.

Point this behavior out in the kerneldoc comment.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
firewire: ohci: replace vm_map_ram() with vmap() 2014-11-19T10:57:50+00:00 Clemens Ladisch clemens@ladisch.de 2014-11-16T20:08:49+00:00 51b04d59c27430a57c347b55478415c342009035 vm_map_ram() is intended for short-lived objects, so using it for the AR buffers could fragment address space, especially on a 32-bit machine. For an allocation that lives as long as the device, vmap() is the better choice. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 
vm_map_ram() is intended for short-lived objects, so using it for the AR
buffers could fragment address space, especially on a 32-bit machine.
For an allocation that lives as long as the device, vmap() is the better
choice.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>