From: James Bottomley <James.Bottomley@SteelEye.com>
To: David Caldwell <david@porkrind.org>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [SCSI] Add support for braindead Cypress USB ATA passthrough CDBs
Date: Fri, 23 Dec 2005 14:34:30 -0600 [thread overview]
Message-ID: <1135370071.3728.43.camel@mulgrave> (raw)
In-Reply-To: <FEB7BF7CC02839AFCC0CF35D@dev.porkrind.org>
On Fri, 2005-12-23 at 11:12 -0800, David Caldwell wrote:
> > I think this approach is too invasive to the stack. When this was
> > discussed in november, there wasn't much enthusiasm for resurrecting the
> > long dead LUN_INHIBIT flag. The two suggested mechanisms are
>
> Invasive because of the extra flag in the request structure?
Yes. But also having users determine this is wrong when it's a device
feature.
> > 2) If 1) doesn't work, then use a blacklist entry which the subsystems
> > would also have access to.
>
> I think this might not be optimal. The problem is that it's impossible to
> tell that it's a Cypress part from the USB side of things (or the SCSI side
> for that matter), so there would have to be an entry for each of the 50,000
> vendors of USB bridges.
I meant use it in the way usb uses other blacklist flags: set them from
slave_configure.
> What about the patch's cdb length additions in sg and scsi_lib.c? It seems
> like half the code guesses CDB length and the other half passes it around.
> Clearly, given devices like this, guessing isn't going to work 100% of the
> time. So either eveyone needs to pass around lengths, or there needs to be
> another flag somewhere. The code should at least be consistent though.
I don't think they're necessary, are they? Zero in cmnd_len means
mid-layer determines size. What it prevents is the issuing of vendor
specific commands via the API, which is arguably a good thing.
James
next prev parent reply other threads:[~2005-12-23 20:34 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
2005-12-23 19:12 ` David Caldwell
2005-12-23 20:34 ` James Bottomley [this message]
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=1135370071.3728.43.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=david@porkrind.org \
--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.