'0' is now used as the default cmd_per_lun value,
so there's no need to explicitly set it to '1' in the
host template.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
[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-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>
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>
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>
PREPARE_[DELAYED_]WORK() are being phased out. They have few users
and a nasty surprise in terms of reentrancy guarantee as workqueue
considers work items to be different if they don't have the same work
function.
firewire core-device and sbp2 have been been multiplexing work items
with multiple work functions. Introduce fw_device_workfn() and
sbp2_lu_workfn() which invoke fw_device->workfn and
sbp2_logical_unit->workfn respectively and always use the two
functions as the work functions and update the users to set the
->workfn fields instead of overriding work functions using
PREPARE_DELAYED_WORK().
This fixes a variety of possible regressions since a2c1c57be8
"workqueue: consider work function when searching for busy work items"
due to which fw_workqueue lost its required non-reentrancy property.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-devel@lists.sourceforge.net
Cc: stable@vger.kernel.org # v3.9+
Cc: stable@vger.kernel.org # v3.8.2+
Cc: stable@vger.kernel.org # v3.4.60+
Cc: stable@vger.kernel.org # v3.2.40+
Commit 54b2b50c20 "[SCSI] Disable WRITE SAME for RAID and virtual
host adapter drivers" disabled WRITE SAME support for all SBP-2 attached
targets. But as described in the changelog of commit b0ea5f19d3
"firewire: sbp2: allow WRITE SAME and REPORT SUPPORTED OPERATION CODES",
it is not required to blacklist WRITE SAME.
Bring the feature back by reverting the sbp2.c hunk of commit 54b2b50c20.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: stable@kernel.org
Some host adapters do not pass commands through to the target disk
directly. Instead they provide an emulated target which may or may not
accurately report its capabilities. In some cases the physical device
characteristics are reported even when the host adapter is processing
commands on the device's behalf. This can lead to adapter firmware hangs
or excessive I/O errors.
This patch disables WRITE SAME for devices connected to host adapters
that provide an emulated target. Driver writers can disable WRITE SAME
by setting the no_write_same flag in the host adapter template.
[jejb: fix up rejections due to eh_deadline patch]
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: stable@kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
FireWire upper layer drivers are converted from generic
struct driver.probe() and .remove()
to bus-specific
struct fw_driver.probe() and .remove().
The new .probe() adds a const struct ieee1394_device_id *id argument,
indicating the entry in the driver's device identifiers table which
matched the fw_unit to be probed. This new argument is used by the
snd-firewire-speakers driver to look up device-specific parameters and
methods. There is at least one other FireWire audio driver currently in
development in which this will be useful too.
The new .remove() drops the unused error return code.
Although all in-tree drivers are being converted to the new methods,
support for the old methods is left in place in this commit. This
allows public developer trees to merge this commit and then move to the
new fw_driver methods.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Clemens Ladisch <clemens@ladisch.de> (for sound/firewire/)
Cc: Peter Hurley <peter@hurleysoftware.com> (for drivers/staging/fwserial/)
No need to crash and burn if S/G element sizes cannot be set to our
liking; just leave a message in the log.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The old IEEE 1394 driver stack was removed in v2.6.37. That made the
checks for two Kconfig (module) macros unneeded, since they will now
always evaluate to true. Remove these two checks.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The commits
3c6bdaeab4 "[SCSI] Add a report opcode helper"
5db44863b6 "[SCSI] sd: Implement support for WRITE SAME"
introduced in-kernel uses of the mentioned commands but cautiously
blacklisted them for any IEEE 1394 (SBP-2/3) targets and some other
transports.
I looked through a range of SBP devices and found that the blacklist
flags can be removed:
The kernel never attempts these commands if the device's INQUIRY
data claim a SCSI revision of less than 0x05. This is the case with
all SBP devices that I checked, except for three more recent devices
which claimed a revision of 0x05 i.e. conformance with SPC-3 (two
devices based on the OXUF936QSE chip but having different firmwares,
one based on OXUF934DSB.)
I tried "sg_opcodes" from sg3_utils on several older and newer devices
and did not encounter any apparent firmware bugs with it. All devices
returned Illegal Request/ Invalid command operation code and carried on.
I furthermore tried "sg_write_same -U" on the OXUF934DSB device with the
same result. Alas I did not have a TRIM enabled SSD available for these
tests. All of the bridges were correctly identified by the kernel as
"fully provisioned", CD-ROM devices aside.
The kernel won't issue WRITE SAME to fully provisioned devices, nor
would it attempt REPORT SUPPORTED OPERATION CODES or WRITE SAME with
UNMAP bit on devices which do not claim conformance to SPC-3 or later.
Hence let's remove the no_report_opcodes and no_write_same blacklist
flags so that these commands can be used on newer targets with
respective capabilities. I guess the Linux sbp-target could be such a
target.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Implement support for WRITE SAME(10) and WRITE SAME(16) in the SCSI disk
driver.
- We set the default maximum to 0xFFFF because there are several
devices out there that only support two-byte block counts even with
WRITE SAME(16). We only enable transfers bigger than 0xFFFF if the
device explicitly reports MAXIMUM WRITE SAME LENGTH in the BLOCK
LIMITS VPD.
- max_write_same_blocks can be overriden per-device basis in sysfs.
- The UNMAP discovery heuristics remain unchanged but the discard
limits are tweaked to match the "real" WRITE SAME commands.
- In the error handling logic we now distinguish between WRITE SAME
with and without UNMAP set.
The discovery process heuristics are:
- If the device reports a SCSI level of SPC-3 or greater we'll issue
READ SUPPORTED OPERATION CODES to find out whether WRITE SAME(16) is
supported. If that's the case we will use it.
- If the device supports the block limits VPD and reports a MAXIMUM
WRITE SAME LENGTH bigger than 0xFFFF we will use WRITE SAME(16).
- Otherwise we will use WRITE SAME(10) unless the target LBA is beyond
0xFFFFFFFF or the block count exceeds 0xFFFF.
- no_write_same is set for ATA, FireWire and USB.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The REPORT SUPPORTED OPERATION CODES command can be used to query
whether a given opcode is supported by a device. Add a helper function
that allows us to look up commands.
We only issue RSOC if the device reports compliance with SPC-3 or
later. But to err on the side of caution we disable the command for ATA,
FireWire and USB.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The SBP-2/3 specifications do not require any alignment of data
buffers; only their own data structures need to be quadlet-aligned
[SR: or octlet-aligned].
Fix the comments to reflect this, but leave the actual alignment at
32 bits to avoid theoretical problems with target implementations
that might handle this incorrectly.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The SCSI framework automatically initializes the block queue's segment
size with the DMA device's segment size.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Use the scsi_dma_map/scsi_dma_unmap helper to simplify the code
a little.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The sbp2 driver does DMA not on the unit but on the card device.
The driver worked even with the wrong device because at the moment, it
happens to reimplement the DMA functions of the SCSI framework.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Remove all #inclusions of asm/system.h preparatory to splitting and killing
it. Performed with the following command:
perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: David Howells <dhowells@redhat.com>
Pull IEEE 1394 (FireWire) subsystem updates post v3.3 from Stefan Richter:
- Some SBP-2 initiator fixes, side product from ongoing work on a target.
- Reintroduction of an isochronous I/O feature of the older ieee1394 driver
stack (flush buffer completions); it was evidently rarely used but not
actually unused. Matching libraw1394 code is already available.
- Be sure to prefix all kernel log messages with device name or card name,
and other logging related cleanups.
- Misc other small cleanups, among them a small API change that affects
sound/firewire/ too. Clemens Ladisch is aware of it.
* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: (26 commits)
firewire: allow explicit flushing of iso packet completions
firewire: prevent dropping of completed iso packet header data
firewire: ohci: factor out iso completion flushing code
firewire: ohci: simplify iso header pointer arithmetic
firewire: ohci: optimize control bit checks
firewire: ohci: remove unused excess_bytes field
firewire: ohci: copy_iso_headers(): make comment match the code
firewire: cdev: fix IR multichannel event documentation
firewire: ohci: fix too-early completion of IR multichannel buffers
firewire: ohci: move runtime debug facility out of #ifdef
firewire: tone down some diagnostic log messages
firewire: sbp2: replace a GFP_ATOMIC allocation
firewire: sbp2: Fix SCSI sense data mangling
firewire: sbp2: Ignore SBP-2 targets on the local node
firewire: sbp2: Take into account Unit_Unique_ID
firewire: nosy: Use the macro DMA_BIT_MASK().
firewire: core: convert AR-req handler lock from _irqsave to _bh
firewire: core: fix race at address_handler unregistration
firewire: core: remove obsolete comment
firewire: core: prefix log messages with card name
...
sbp2_send_management_orb() is called by sbp2_login, sbp2_reconnect, and
sbp2_remove, all which are able to sleep during memory allocations.
Actually, sbp2_send_management_orb() itself is a sleeping function.
Login and remove could allocate with GFP_KERNEL but reconnect needs
GFP_NOIO to ensure progress in low memory situations.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
SCSI sense data in SBP-2/3 is carried in an unusual format that means we
have to un-mangle it on our end before we pass it to the SCSI subsystem.
Currently our un-mangling code doesn't quite follow the SBP-2 standard
in that we always assume Current and never Deferred error types, we
never set the VALID bit, and we mishandle the FILEMARK, EOM and ILI
bits.
This patch fixes the sense un-mangling to correctly handle those and
follow the spec.
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The firewire-sbp2 module tries to login to an SBP-2/3 target even when
it is running on the local node, which fails because of the inability to
fetch data from DMA mapped regions using firewire transactions on the
local node. It also doesn't make much sense to have the initiator and
target on the same node, so this patch prevents this behaviour.
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changed the comment)
If the target's unit directory contains a Unit_Unique_ID entry, we
should use that as the target's GUID for identification purposes. The
SBP-2 standards document says:
"Although the node unique ID (EUI-64) present in the bus information
block is sufficient to uniquely identify nodes attached to Serial Bus,
it is insufficient to identify a target when a vendor implements a
device with multiple Serial Bus node connections. In this case initiator
software requires information by which a particular target may be
uniquely identified, regardless of the Serial Bus access path used."
[ IEEE T10 P1155D Revision 4, Section 7.6 (page 51) ] and
[ IEEE T10 P1467D Revision 5, Section 7.9 (page 74) ]
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Hannes Reinecke
Stefan Richter
Tejun Heo
Martin K. Petersen
Paul Bolle
Clemens Ladisch
David Howells
Linus Torvalds
Chris Boot