... is usb-storage forcing scsi-2 when the device tells us it is
scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet
requiring non-LUN value in cdb[1]?
The very newest devices that pass info thru mask xE0 of cdb[1] may be
reporting SCSI zero, especially when the cable is not SPI &
especially when Peripheral Device Type (mask x1F of byte 0 of Inquiry
data) is nonzero.
We were told in prior emails that it actually reports a level of zero
(i.e. no compliance with any SCSI standard)
People dispute what zero means in byte 2 of SCSI Inquiry data. Here
are five widely disseminated opinions:
a) T10 s1-r17b: "Version is unspecified. (Use this code if you are
implementing to this document - it is not published, yet.)"
b) T10 s1-r17b: "does not claim compliance to the ISO or ECMA
versions of SCSI".
c) T10 s2-r10l.pdf: "might or might not comply to an ANSI-approved
standard"
d) T10 s2-r10l.pdf: "does not claim compliance to the ISO or ECMA
versions of SCSI".
e) SFF sff8020i.pdf: [mask x07] "must contain a zero to comply with
this version of the Specification"
See that? Often, the very same document disagrees with itself.
Nowadays, the SFF heresy has grown to where T10 simultaneous
publishes two or more distinct definitions of Inquiry - the SPC
definition and the MMC definition.
SPC Inquiry data bytes 58 and following now have "version descriptor"
definitions that let a device that zeroes byte 2 say more, in
theory. I haven't actually seen anyone populate those fields in a
mass market product?
...
I'd think that everyone should accept that trying to reclaim mask xFF
in the last CDB byte and mask xE0 of CDB byte 1 is rude ... I'm not
sure what rationally motivates those movements in device design that
demand greater transparency of a pass thru SCSI host.
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
