Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e423ee31db92d4e298c137814a4341e1cd05739e
Commit: e423ee31db92d4e298c137814a4341e1cd05739e
Parent: a29fdd3c2a3e53b67baa5031372fd78fddaf48fa
Author: Alan Stern <[EMAIL PROTECTED]>
AuthorDate: Fri Feb 16 01:46:38 2007 -0800
Committer: James Bottomley <[EMAIL PROTECTED]>
CommitDate: Fri Feb 16 10:13:01 2007 -0600
[SCSI] scsi_scan.c: handle bad inquiry responses
A particular USB device has been reporting short inquiry lengths. The
SCSI code cannot operate properly unless we get an inquiry length of
36 or above (because of the way we parse vendor and product), so
assume at least 36 bytes are valid even if the device reports fewer.
This is wrong, but it's no worse than what we're doing now (using the
garbage beyond the last reported valid byte).
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_scan.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index a43b9ec..7757e55 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -654,6 +654,19 @@ static int scsi_probe_lun(struct scsi_device *sdev,
unsigned char *inq_result,
* short INQUIRY), an abort here prevents any further use of the
* device, including spin up.
*
+ * On the whole, the best approach seems to be to assume the first
+ * 36 bytes are valid no matter what the device says. That's
+ * better than copying < 36 bytes to the inquiry-result buffer
+ * and displaying garbage for the Vendor, Product, or Revision
+ * strings.
+ */
+ if (sdev->inquiry_len < 36) {
+ printk(KERN_INFO "scsi scan: INQUIRY result too short (%d),"
+ " using 36\n", sdev->inquiry_len);
+ sdev->inquiry_len = 36;
+ }
+
+ /*
* Related to the above issue:
*
* XXX Devices (disk or all?) should be sent a TEST UNIT READY,
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
