Robert Hancock wrote:
This doesn't seem a very reliable way to identify an IDE device, as all
that 0 means is that the device does not claim conformance to any
standard. I would think it would be legitimate for an IDE device to put
a value like 5 in there as well, if it complies with SPC-4..
Via the this-doesnt-really-matter-but-it-should-be-noted department:
According to the latest on t10.org, MMC retroactively permitted SCSI
version to be zero, for MMC-compliant USB and ATAPI devices.
In the case of libata though, that appears to be due to this code in
drivers/ata/libata-scsi.c:
/* ATAPI devices typically report zero for their SCSI version,
* and sometimes deviate from the spec WRT response data
* format. If SCSI version is reported as zero like normal,
* then we make the following fixups: 1) Fake MMC-5 version,
* to indicate to the Linux scsi midlayer this is a modern
* device. 2) Ensure response data format / ATAPI information
* are always correct.
*/
if (buf[2] == 0) {
buf[2] = 0x5;
buf[3] = 0x32;
}
This technically seems to go against what the SCSI/ATA Translation (SAT)
spec says regarding INQUIRY on ATAPI devices: "the SATL shall use the
ATA PACKET Command feature set to pass all INQUIRY commands and
parameter data to the ATAPI device without altering the INQUIRY
commands or the parameter data." However, it might realistically be
needed if the SCSI layer in the kernel has problems with a device
indicating it supports no SCSI version..
The above tweak is entirely software->software communication... as the
comment you quoted notes, it's just a signal to the SCSI midlayer.
At the moment, the SCSI midlayer assumes any device that reports scsi
version as less than 2 is forced to SCSI version 2. Ultimately that's
incorrect behavior for all ATAPI devices (and later MMC revisions).
At the time, libata simply worked around this SCSI buglet in its own
code, since that was easier than auditing all SCSI code paths to ensure
new ATAPI/USB MMC logic does not break ancient devices.
But if someone is motivated enough to revisit this...
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
