All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: David Caldwell <david@porkrind.org>, linux-scsi@vger.kernel.org
Subject: Re: [SCSI] Add support for braindead Cypress USB ATA passthrough CDBs
Date: Fri, 23 Dec 2005 11:59:29 -0600	[thread overview]
Message-ID: <1135360770.3728.27.camel@mulgrave> (raw)
In-Reply-To: <43AC36B5.3000209@pobox.com>

On Fri, 2005-12-23 at 12:41 -0500, Jeff Garzik wrote:
> James Bottomley wrote:
> > 1) Simply don't mangle the LUN for SCSI_UNKNOWN and then have all the
> > subsystems lying about SCSI_2 compliance instead set their mangled level
> > to SCSI_UNKNOWN (which seems to be more truthful)
> 
> It is specified in MMC that ATAPI or USB may be SCSI level to zero. 
> Thus "lying" is not really accurate at all.  We need to update SCSI to 
> handle these devices as specified.

Isn't that what I proposed?

But it only fixes the devices whose SCSI level is correctly passed on to
the mid-layer.  There's still the problem of USB and other subsystems
mangling the level back to SCSI_2 which causes the LUN to be placed in
cdb[1] as per spec.  

> This is why I snoop INQUIRY for ATAPI devices in libata-scsi, and force 
> the SCSI version to 0x05, if SCSI version is returned from the device as 
> zero.  It is conditional because -- due to the wonderful world of 
> hardware -- some ATAPI devices (such as SCSI devices plugged into an 
> SPI<->ATA bridge) and some USB devices correctly report SCSI version.

Well, that's SCSI3 (SPC-3), which is fine, but does mean we try
REPORT_LUNS scanning.  The problem in other subsystems is that some
devices hang when they see a REPORT_LUNS command.

What problems do you see returning zero (apart from cdb[1] changes)?

James



  reply	other threads:[~2005-12-23 18:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21 12:24 [SCSI] Add support for braindead Cypress USB ATA passthrough CDBs David Caldwell
2005-12-22  9:24 ` thomas schorpp
2005-12-22 20:22   ` David Caldwell
2005-12-23 15:52 ` James Bottomley
2005-12-23 17:41   ` Jeff Garzik
2005-12-23 17:59     ` James Bottomley [this message]
2005-12-23 19:12   ` David Caldwell
2005-12-23 20:34     ` James Bottomley
2005-12-23 21:13       ` David Caldwell
2005-12-24  3:28         ` Douglas Gilbert
2005-12-24  7:11           ` David Caldwell

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=1135360770.3728.27.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=david@porkrind.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-scsi@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.