linux/include/scsi, branch v2.6.27.7

[SCSI] fix check of PQ and PDT bits for WLUNs

2008-08-29T14:19:11Z

For IBM z series certain LUNs can no longer be accessed. This is because kernel version 2.6.19 a check was introduced not to create a generic SCSI device for devices that return PQ=1 and PDT=0x1f. For WLUNs (see SAM-3, p. 41ff) generic SCSI devices should be created unconditionally without looking at the PQ bit, so add a check for WLUNs in with this test. Acked-by: Martin Petermann Signed-off-by: James Bottomley

[SCSI] sd: fix USB devices incorrectly reporting DIF support

2008-08-06T17:49:23Z

Some USB devices set the protect bit in the INQUIRY data which currently causes the DIF code in sd to assume (incorrectly) that they support READ_CAPACITY(16). Fix this (only for the time being) by making sure we only believe the protect bit in the inquiry data if the device claims conformance to SCSI-3 or above. Acked-by: Martin K. Petersen Signed-off-by: James Bottomley

Re-introduce "[SCSI] extend the last_sector_bug flag to cover more sectors"

2008-08-06T04:42:21Z

This re-introduces commit 2b142900784c6e38c8d39fa57d5f95ef08e735d8, which was reverted due to the regression it caused by commit fca082c9f1e11ec07efa8d2f9f13688521253f36. That regression was not root-caused by the original commit, it was just uncovered by it, and the real fix was done by Alan Stern in commit 580da34847488b404218d1d7f53b156f245f5555 ("Fix USB storage hang on command abort"). We can thus re-introduce the change that was confirmed by Alan Jenkins to be still required by his odd card reader. Cc: Alan Jenkins Cc: Alan Stern Cc: James Bottomley Signed-off-by: Linus Torvalds

Revert "[SCSI] extend the last_sector_bug flag to cover more sectors"

2008-08-04T23:36:20Z

This reverts commit 2b142900784c6e38c8d39fa57d5f95ef08e735d8, since it seems to break some other USB storage devices (at least a JMicron USB to ATA bridge). As such, while it apparently fixes some cardreaders, it would need to be made conditional on the exact reader it fixes in order to avoid causing regressions. Cc: Alan Jenkins Cc: James Bottomley Signed-off-by: Linus Torvalds

[SCSI] extend the last_sector_bug flag to cover more sectors

2008-07-27T14:16:13Z

The last_sector_bug flag was added to work around a bug in certain usb cardreaders, where they would crash if a multiple sector read included the last sector. The original implementation avoids this by e.g. splitting an 8 sector read which includes the last sector into a 7 sector read, and a single sector read for the last sector. The flag is enabled for all USB devices. This revealed a second bug in other usb cardreaders, which crash when they get a multiple sector read which stops 1 sector short of the last sector. Affected hardware includes the Kingston "MobileLite" external USB cardreader and the internal USB cardreader on the Asus EeePC. Extend the last_sector_bug workaround to ensure that any access which touches the last 8 hardware sectors of the device is a single sector long. Requests are shrunk as necessary to meet this constraint. This gives us a safety margin against potential unknown or future bugs affecting multi-sector access to the end of the device. The two known bugs only affect the last 2 sectors. However, they suggest that these devices are prone to fencepost errors and that multi-sector access to the end of the device is not well tested. Popular OS's use multi-sector accesses, but they rarely read the last few sectors. Linux (with udev & vol_id) automatically reads sectors from the end of the device on insertion. It is assumed that single sector accesses are more thoroughly tested during development. Signed-off-by: Alan Jenkins Tested-by: Alan Jenkins Signed-off-by: James Bottomley

[SCSI] scsi_eh_prep_cmnd should save scmd->underflow

2008-07-26T19:14:56Z

This patch (as1116) fixes a bug in scsi_eh_prep_cmnd() and scsi_eh_restore_cmnd(). These routines are supposed to save any values they change and restore them later, but someone forgot to save & restore scmd->underflow. This fixes part of the problem reported in Bugzilla #9638. [jejb: fix up rejections around DIF/DIX] Signed-off-by: Alan Stern Signed-off-by: James Bottomley

[SCSI] Support devices with protection information

2008-07-26T19:14:55Z

Implement support for DMA of protection information for devices that are data integrity capable. - Add support for mapping an extra scatter-gather list containing the protection information. - Allocate protection scsi_data_buffer if host is DIX (integrity DMA) capable. - Accessor function for checking whether a device has protection enabled. Signed-off-by: Martin K. Petersen Signed-off-by: James Bottomley

[SCSI] Command protection operation

2008-07-26T19:14:54Z

Controllers that support DMA of protection information must be told explicitly how to handle the I/O. The controller has no knowledge of the protection capabilities of the target device so this information must be passed in the scsi_cmnd. - The protection operation tells the HBA whether to generate, strip or verify protection information. - The protection type tells the HBA which layout the target is formatted with. This is necessary because the controller must be able to correctly interpret the included protection information in order to verify it. - When a scsi_cmnd is reused for error handling the protection operation must be cleared and saved while error handling is in progress. - prot_op and prot_type are placed in an existing hole in scsi_cmnd and don't cause the structure to grow. Signed-off-by: Martin K. Petersen Signed-off-by: James Bottomley

[SCSI] Host protection capabilities

2008-07-26T19:14:54Z

Controllers that support protection information must indicate this to the SCSI midlayer so that the ULD can prepare scsi_cmnds accordingly. This patch implements a host mask and various types of protection: - DIF Type 1-3 (between HBA and disk) - DIX Type 0-3 (between OS and HBA) The patch also allows the HBA to set the guard type to something different than the T10-mandated CRC. Signed-off-by: Martin K. Petersen Signed-off-by: James Bottomley

[SCSI] scsi_dh: attach to hardware handler from dm-mpath

2008-07-26T19:14:53Z

multipath keeps a separate device table which may be more current than the built-in one. So we should make sure to always call ->attach whenever a multipath map with hardware handler is instantiated. And we should call ->detach on removal, too. [sekharan: update as per comments from agk] Signed-off-by: Hannes Reinecke Signed-off-by: Chandra Seetharaman Signed-off-by: James Bottomley