> > Hi all, > > > > I have a USB bridge that's implementing SAT passthru cdbs. > We ran into an > > issue with the usb-storage driver in that when it does > auto-sense (because > > the CK_COND bit is set in the passthru cdb), the driver > does a sense with > > only 18 bytes for the sense buffer. The problem is that > SAT passthru wants > > to return 22 bytes of sense data. The last 4 bytes that > don't get returned > > are fairly important ATA task files registers: lba high > hob, lba high, > > device, and status. > > > > For testing purposes I use the patch below, but what's the > correct way to > > deal with this issue? Is there something in the USB spec > mandating 18 bytes > > of sense data, or is the usb-storage simply making a > hard-coded assumption? > > I believe it's a hard-coded assumption, based on the > observation that many > USB devices don't like it if you ask for more or less than 18 > bytes. Matt > Dharm can correct this if I'm wrong. > > The sense buffer length is yet another quantity that ought to > have an SG > passthru but doesn't. >
SG_IO provides a field that allows the application to dictate the maximum sense buffer length to be passed back. Could this field also mean the "expected" length and somehow its meaning is passed through the scsi system so that usb-storage can use that as the length? So if the value isn't available, it defaults to 18, but if the application "knows better" it can basically tell usb-storage (or any other backend) to use a different length? > Your patch looks to me like a reasonable approach, given the > constraints > we are under. It would be nice to have a cleaner way of > determining which > commands need the extra sense data. Could you make that test into a > separate subroutine? And perhaps use symbolic names for the command > bytes. not a problem. Thanks, Tim Thelin
