From: James Bottomley <James.Bottomley@steeleye.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Matthew Dharm <mdharm-scsi@one-eyed-alien.net>,
Andries.Brouwer@cwi.nl, greg@kroah.com,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
linux-usb-devel@lists.sourceforge.net,
Linus Torvalds <torvalds@transmeta.com>,
usb-storage@one-eyed-alien.net
Subject: Re: [usb-storage] Re: PATCH: exclude certain commands from emulated SCSI hosts
Date: 22 Apr 2003 11:07:15 -0500 [thread overview]
Message-ID: <1051027636.1768.56.camel@mulgrave> (raw)
In-Reply-To: <1051021911.14880.25.camel@dhcp22.swansea.linux.org.uk>
On Tue, 2003-04-22 at 09:31, Alan Cox wrote:
> On Maw, 2003-04-22 at 02:17, Matthew Dharm wrote:
> > Your patches went a long way to improving things. But, then people added
> > EVPD and further changed MODE_SENSE and other things. It's pretty clear
> > to me that trying to change the SCSI core to not use these commands isn't
> > going to happen -- so I want a way to filter them. I originally wanted a
> > centralized filter (i.e. usb-storage could indicate to the mid-layer not to
> > send the 'unwelcome' commands), but that got shot down in favor of a
> > centralized filter-framework which could be applied by any LLDD that wanted
> > to.
>
> You already can do this. You just need to write yourself a library
> routine which converts/blocks according to the filter rules (ie
> read6->read10, returns errors to fancy stuff etc).
Actually, this one should already be fixed in the mid-layer. We use
READ_10/WRITE_10 by default (device->ten flag, which is initialised to
1). We only revert back to READ_6 if the device rejects the 10 byte
command.
We also use READ_16, but *only* if the requested block is over the
READ_10 limit (2Tb) so this should never be a problem.
We have been changing the probing ordering and command type in the
mid-layer to cope with these cases. (for instance, Andries noticed that
we could avoid annoying removable media by not probing for capacity and
cache type unless the media is actually present, not probing for write
protect unless the media is removeable).
However, we seem to have reached the point over the cache probe and the
write protect probe where there are no more ordering change tricks that
can be used.
The relevant bugzilla bugs are
http://bugzilla.kernel.org/show_bug.cgi?id=211 (Mounting a SM/CF reader
does not work and does not return)
http://bugzilla.kernel.org/show_bug.cgi?id=553 (On connecting Sony
TRV340E camera in USB mode, USB hangs)
http://bugzilla.kernel.org/show_bug.cgi?id=510 (USB storage doesn't work
on my Sony Vaio C1VE)
A lot of the problems seem to be memory stick related.
The plan is to put a filter library into scsi_lib which could be called
from the usb-storage queuecommand() to filter out the offending commands
with the correct sense rejections that the mid-layer can process and
recover from.
James
next prev parent reply other threads:[~2003-04-22 15:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-22 1:09 [usb-storage] Re: PATCH: exclude certain commands from emulated SCSI hosts Andries.Brouwer
2003-04-22 1:17 ` Matthew Dharm
2003-04-22 14:31 ` Alan Cox
2003-04-22 15:36 ` Matthew Dharm
2003-04-22 15:05 ` [linux-usb-devel] " Alan Cox
2003-04-22 18:48 ` Matthew Dharm
2003-04-22 16:07 ` James Bottomley [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-04-22 18:44 Andries.Brouwer
2003-04-22 17:38 Andries.Brouwer
2003-04-22 18:23 ` Alan Stern
2003-04-22 17:22 Andries.Brouwer
2003-04-22 17:34 ` Mike Bursell
2003-04-22 17:37 ` James Bottomley
2003-04-22 18:50 ` Matthew Dharm
2003-04-22 17:08 Andries.Brouwer
2003-04-09 15:15 Pat LaVarre
2003-04-09 15:08 Pat LaVarre
2003-04-08 13:29 Pat LaVarre
2003-04-09 7:45 ` Douglas Gilbert
2003-03-24 19:16 Pat LaVarre
2003-03-24 20:20 ` Matthew Dharm
2003-03-24 18:17 Pat LaVarre
2003-03-24 18:19 ` Jens Axboe
2003-03-23 7:31 Matthew Dharm
2003-03-23 7:39 ` Linus Torvalds
2003-03-23 18:13 ` [usb-storage] " Matthew Dharm
2003-03-24 1:05 ` Douglas Gilbert
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=1051027636.1768.56.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=greg@kroah.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mdharm-scsi@one-eyed-alien.net \
--cc=torvalds@transmeta.com \
--cc=usb-storage@one-eyed-alien.net \
/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