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

Matthew Dharm
2005-11-06T21:59:10Z

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

On Sat, Nov 05, 2005 at 06:49:05PM -0600, James Bottomley wrote:
> On Sat, 2005-11-05 at 15:55 -0800, Matthew Dharm wrote:
> > On Fri, Nov 04, 2005 at 02:49:55PM -0600, James Bottomley wrote:
> > > Can you just try it with a modern kernel and see if anything still
> > > breaks?
> >
> > I just realized this plan has a problem...
> >
> > The reported SCSI level of a device is mostly garbage, but not always.
> > I've seen 0, 1, 2, 3, and 0xff all reported. HOWEVER, the reported value
> > seems independent of what devices have vendor-specific commands (and thus
> > need the CDB[1] not messed with).
> >
> > It is an interesting experiment to remove the force-to-SCSI_2 part of the
> > usb-storage code (on the general principal of "we shouldn't be messing with
> > the data passed through the driver), but it doesn't solve the original
> > question of needing a way to pass commands without CDB[1] getting altered.
>
> Well, that might be a problem if it weren't for the fact that this
> LUN_INHIBIT flag was removed in 2002. If it's taken three years to find
> a device that has a problem with it, I don't really think it's a
> particularly widespread problem. And since the device that now shows
> the problem is setting the level to 0, it looks like we have a potential
> solution that fits all known cases.

Was it really removed that long ago? I guess there are still a lot of
people using 2.4 kernels, then.

I've been recommending this flag to people as recently as 6 months ago
(i.e. the last time someone asked me). It comes up 2-3 times a year.

The last time it came up, the device set SCSI_2.

Matt

--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver

It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]