public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Pat LaVarre <p.lavarre@ieee.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>,
	Patrick Mansfield <patmans@us.ibm.com>,
	USB Storage List <usb-storage@lists.one-eyed-alien.net>,
	SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: [usb-storage] Time to allow MODE SENSE for USB disk-type storage de vices?
Date: 08 Mar 2004 10:55:20 -0700	[thread overview]
Message-ID: <1078768520.2341.54.camel@patibmrh9> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0403081046190.1187-100000@ida.rowland.org>

> On a related note, we've run across reports from several users
> indicating that their USB devices die when handed a PREVENT-ALLOW
> MEDIUM REMOVAL command, even though they set the Removable-Medium flag
> in their INQUIRY data.  Could there be a device flag that would cause
> the sd driver to avoid these commands?

I hear op x1E Prevent/ Allow appears in Windows bus traces.

I wonder what cbw/ sequence avoids killing such devices for Windows.

> Windows uses MODE SENSE(6) for Transparent Scsi (USB SubClass =
> 0x06) and MODE SENSE(10) for everything else -- according to Pat LaVarre
> anyway, and it agrees with the trace data.  (MODE SELECT is treated the
> same way, but that's irrelevant for our purposes.)

(-: I doubt I ever said anything so easily understood. :-)

More precisely I imagine I actually have said that my limited experience
of ATAPI & USB Windows bus traces confirms the published portions of
Microsoft's host-vendor-specific definition of USB Mass
bInterfaceSubClass x06, in particular:

--- http://www.google.com/search?q=microsoft+design+usb
---
--- second hit today
--- http://www.microsoft.com/whdc/hwdev/bus/USB/default.mspx
---
--- FAQ for USB Storage Support in Windows
--- http://www.microsoft.com/whdc/hwdev/bus/usb/usbfaq.mspx

Usbstor.sys and Device Class Support
Q: Which device classes does usbstor.sys understand?
In Windows XP, Windows 2000, and Windows Me, usbstor.sys makes only one
distinction: 

bInterfaceSubClass == 06h 
- OR - 
bInterfaceSubClass != 06h 

The value bInterfaceSubClass == 06h means that:

Command descriptor blocks (CDBs) should not be padded to 12 bytes.

Mode Sense / Mode Select commands should not be translated from 1AH /
15h to 5AH / 55h.

Subclass 0x06 should generally be used for flash memory devices.

The value bInterfaceSubClass != 06h means that:

CDBs should be padded to 12 bytes.

Mode Sense / Mode Select commands should be translated from 1AH / 15h to
5AH / 55h.

---

Pat LaVarre

P.S.

I wonder if our collected Windows USB Mass traces show that t10.org SBC
neglects to emphasise op x23 is HOST-vendor-specific.

P.P.S.

If we choose to teach Linux to talk more like Windows here, then of
course I hope we still allow ioctl SG_IO, CDROM_SEND_PACKET, etc. to
pass SCSI thru transparently, especially to bInterfaceSubClass x06.

I remember thinking in/correctly that devices of
drivers/usb/storage/unusual_devs.h connect transparently only with a
patched kernel.



  reply	other threads:[~2004-03-08 17:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-08 16:05 Time to allow MODE SENSE for USB disk-type storage devices? Alan Stern
2004-03-08 17:55 ` Pat LaVarre [this message]
2004-03-08 21:16   ` [usb-storage] Time to allow MODE SENSE for USB disk-typestorage de vices? Pat LaVarre
2004-03-08 20:13 ` [usb-storage] Time to allow MODE SENSE for USB disk-type storage devices? Andries Brouwer
2004-03-10  1:43   ` Patrick Mansfield
2004-03-10  9:13     ` Andries Brouwer
2004-03-10 16:56       ` Alan Stern
2004-03-10 18:53       ` [usb-storage] Time to allow MODE SENSE for USB disk-type storag edevices? Pat LaVarre
2004-03-10 20:24         ` Alan Stern
2004-03-10 20:58           ` Pat LaVarre
2004-03-10 22:43             ` Alan Stern

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=1078768520.2341.54.camel@patibmrh9 \
    --to=p.lavarre@ieee.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mdharm-usb@one-eyed-alien.net \
    --cc=patmans@us.ibm.com \
    --cc=stern@rowland.harvard.edu \
    --cc=usb-storage@lists.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