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

Patrick Mansfield
2005-11-07T20:47:40Z

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