Re: [usb-storage] [Merging ATA passthru] on integrating SMART/ATA-Security in usb-storage driver

[Patrick Mansfield <patmans@us.ibm.com>]

On Mon, Nov 07, 2005 at 02:53:34PM -0500, Alan Stern wrote:
> On Mon, 7 Nov 2005, Patrick Mansfield wrote:
> > Can we trigger black listing based on the above vendor/product values?
> > i.e. can you check for these values in usb-storage slave_configure code?
> 
> Yes.  The patch below illustrates how.  You'll have to change the name of 
> the sdev flag to something sensible...
> 
> I firmly believe this is the wrong approach, however.  It's a specific 
> solution to a general problem.  I would much prefer to add a new flag to 
> struct request.

We have the specific problem of a device being reported as scsi-2
compliant when it is not.

Stepping back a bit ...

usb-storage should pass through the scsi level, we should not require
special handling (adding back inhibit lun support or a new black list
option) for compliant hardware.

So, do we have a usb-storage problem or non-compliant hardware here? I
did not find the answer in previous emails.

That is, is usb-storage forcing scsi-2 when the device tells us it is
scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet
requiring non-LUN value in cdb[1]?

A method that can reliably and easily set some black list value for the
hardware in question will to lead to fewer questions in the future as to
why an SG_IO command is getting LUN values set in cdb[1].

If this is a hardware problem I'm not opposed to adding back support for
the ioctl and AFAIUI a new struct request flag.

-- Patrick Mansfield