aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/scsi/scsi_sysfs.c
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2014-09-02 11:35:50 -0400
committerChristoph Hellwig <hch@lst.de>2014-09-15 19:01:58 -0400
commit50c4e96411a6cd728f04cf70d8d6def57828b320 (patch)
treefd47f80ec189ac23a75ddfcc82c24a428e8da3aa /drivers/scsi/scsi_sysfs.c
parent64bdcbc449105377dd60c8da97cfc1663b39562c (diff)
scsi: don't store LUN bits in CDB[1] for USB mass-storage devices
The SCSI specification requires that the second Command Data Byte should contain the LUN value in its high-order bits if the recipient device reports SCSI level 2 or below. Nevertheless, some USB mass-storage devices use those bits for other purposes in vendor-specific commands. Currently Linux has no way to send such commands, because the SCSI stack always overwrites the LUN bits. Testing shows that Windows 7 and XP do not store the LUN bits in the CDB when sending commands to a USB device. This doesn't matter if the device uses the Bulk-Only or UAS transports (which virtually all modern USB mass-storage devices do), as these have a separate mechanism for sending the LUN value. Therefore this patch introduces a flag in the Scsi_Host structure to inform the SCSI midlayer that a transport does not require the LUN bits to be stored in the CDB, and it makes usb-storage set this flag for all devices using the Bulk-Only transport. (UAS is handled by a separate driver, but it doesn't really matter because no SCSI-2 or lower device is at all likely to use UAS.) The patch also cleans up the code responsible for storing the LUN value by adding a bitflag to the scsi_device structure. The test for whether to stick the LUN value in the CDB can be made when the device is probed, and stored for future use rather than being made over and over in the fast path. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Tiziano Bacocco <tiziano.bacocco@gmail.com> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'drivers/scsi/scsi_sysfs.c')
-rw-r--r--drivers/scsi/scsi_sysfs.c12
1 files changed, 12 insertions, 0 deletions
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 8b4105a22ac2..85e36f3a5585 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1263,7 +1263,19 @@ void scsi_sysfs_device_initialize(struct scsi_device *sdev)
1263 sdev->sdev_dev.class = &sdev_class; 1263 sdev->sdev_dev.class = &sdev_class;
1264 dev_set_name(&sdev->sdev_dev, "%d:%d:%d:%llu", 1264 dev_set_name(&sdev->sdev_dev, "%d:%d:%d:%llu",
1265 sdev->host->host_no, sdev->channel, sdev->id, sdev->lun); 1265 sdev->host->host_no, sdev->channel, sdev->id, sdev->lun);
1266 /*
1267 * Get a default scsi_level from the target (derived from sibling
1268 * devices). This is the best we can do for guessing how to set
1269 * sdev->lun_in_cdb for the initial INQUIRY command. For LUN 0 the
1270 * setting doesn't matter, because all the bits are zero anyway.
1271 * But it does matter for higher LUNs.
1272 */
1266 sdev->scsi_level = starget->scsi_level; 1273 sdev->scsi_level = starget->scsi_level;
1274 if (sdev->scsi_level <= SCSI_2 &&
1275 sdev->scsi_level != SCSI_UNKNOWN &&
1276 !shost->no_scsi2_lun_in_cdb)
1277 sdev->lun_in_cdb = 1;
1278
1267 transport_setup_device(&sdev->sdev_gendev); 1279 transport_setup_device(&sdev->sdev_gendev);
1268 spin_lock_irqsave(shost->host_lock, flags); 1280 spin_lock_irqsave(shost->host_lock, flags);
1269 list_add_tail(&sdev->same_target_siblings, &starget->devices); 1281 list_add_tail(&sdev->same_target_siblings, &starget->devices);