From: Jeff Garzik <jeff@garzik.org>
To: Mathieu Fluhr <mfluhr@nero.com>
Cc: Robert Hancock <hancockr@shaw.ca>,
LKML <linux-kernel@vger.kernel.org>,
ide <linux-ide@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: Inquiry data and emulated SG devices
Date: Thu, 18 Oct 2007 06:06:37 -0400 [thread overview]
Message-ID: <4717302D.4050107@garzik.org> (raw)
In-Reply-To: <1192701555.3247.28.camel@de-c-l-110.nero-de.internal>
Mathieu Fluhr wrote:
> On Wed, 2007-10-17 at 21:31 -0400, Jeff Garzik wrote:
>> 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.
>>
>
> Quoting to the latest MtFuji draft (Section 17.7.1):
> "The ANSI Version field shall contain a non-zero value to comply with
> this version of the Specification for a SCSI logical unit or zero for
> an ATAPI logical unit."
>
>
>>> 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 explain a lot... But (Sorry I am not a scsi mid-layer expert) why
> faking what the device outputs?
The SCSI midlayer makes a lot of "if scsi version <= 2" choices. In the
case of ATAPI, we do not want to force ATAPI down the path of ancient
SCSI devices, as this disables some MMC features that modern ATAPI
devices support.
Jeff
next prev parent reply other threads:[~2007-10-18 10:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.PgEHbZ0E5ogcX8bZwvrUeZB+eJs@ifi.uio.no>
2007-10-18 1:22 ` Inquiry data and emulated SG devices Robert Hancock
2007-10-18 1:31 ` Jeff Garzik
2007-10-18 9:59 ` Mathieu Fluhr
2007-10-18 10:06 ` Jeff Garzik [this message]
2007-10-18 11:57 ` Mathieu Fluhr
2007-10-18 12:13 ` James Bottomley
2007-10-18 12:44 ` Mathieu Fluhr
2007-10-18 10:57 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4717302D.4050107@garzik.org \
--to=jeff@garzik.org \
--cc=hancockr@shaw.ca \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mfluhr@nero.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).