Re: [usb-storage] Re: [PATCH] fix Sony USB mass storage - pass larger receive buffer

[Pat LaVarre <p.lavarre@ieee.org>]

> > How about we blacklist all the bInterfaceSubClass that Windows does not
> > regard as generic.  I remember Windows does regard bInterfaceSubClass =
> > x06 as generic.  I think I remember there are two others.
> 
> grep -i generic
> in windows/inf/usbstor.inf yields, hex:
> 
> 08 02 50
> 08 05 50
> 08 06 50
> 
> How about we [guess] disk writable
> [without risking mode sense]
> if we do not find bInterfaceSubClass in
> the set x 02 05 06?

In short:

Or how about we only blacklist mode sense from devices that report
bInterfaceSubClass = any of the x07..FF Reserved codes?  Surely a device
sending us a formally Reserved code is a good first clue that it may not
behave robustly thereafter?  Or maybe we just blacklist mode sense from
bInterfaceSubClass = xFF FormallyReservedButInformallyVendorSpecific? 
Surely a device sending us that code is an even better first clue that
it may not behave robustly thereafter?

At length ...

usb.org --> Developers --> Documents --> USB Device Class Specifications
--> Approved yields:

http://www.usb.org/developers/devclass_docs#approved

http://www.usb.org/developers/devclass_docs/usb_msc_overview_1.2.pdf

xpdf then shows, in page 6 of 7, "Table 2.1 - SubClass Codes Mapped to
Command Block Specifications"

x01..x06 = RBC SFF-CD/MMC QIC UFI SFF-FDD SCSI
x07..xFF = "Reserved for future use."

De facto practice says xFF = vendor-specific, by analogy with other
usb.org texts.

Blacklisting mode sense from all but 02 05 06, same as Windows, means
blacklisting all but QIC SFF-FDD SCSI.  Maybe uncomfortably aggressive.

> > Here we have bInterfaceSubClass = xFF ...
> > > That's this device TELLING US THIS DEVICE DOES NOT TALK SCSI.

By the way, kudos to Dmitri Katchalov for including USB descriptors in
the trace, rather than tracing only CDB's & data.

Pat LaVarre