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

[thomas schorpp <t.schorpp@gmx.de>]

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.
> 
> Anyway, the goal should be to handle devices in a standards compliant
> manner first and then worry about quirk tables when that doesn't
> work ... we have an incredibly broad quirk infrastructure in SCSI for
> this.
> 
> James
> 

ok, ive just ordered 2 cypress CY7C68300B samples and will replace the discont'd A type in my device.
datasheet for A says nothing about ATACB and security. sheet for B does guarantee.

cypress windows driver reports no security, too.

so i will replace the chip to have a testing base.

tom