thomas schorpp <t.schorpp <at> gmx.de> writes: > > David Caldwell wrote: > > This patch does 2 things. It reimplements the SG_FLAG_LUN_INHIBIT flag > > in the SG_IO ioctl which stops the scsi subsystem from overwriting the > > 2nd byte of the CDB with the LUN. It also doesn't guess the CDB length > > when sending the SG_IO ioctl to the sg device (the main scsi_ioctl > > already did this). > > > > This is for the Cypress CY7C68310 USB to ATA bridge chip (and most > > likely other USB to ATA chips from Cypress), which implements an ATA > > passthrough command that is 16 bytes long and starts with the bytes > > 0x24 0x24. (Not vendor unique, weird length for opcode 0x24, and > > misuse of the LUN area all at the same time--Lovely). > > thx, hm, that chip is that old that datasheet is available no more... Yeah, the chip I tested with was a CY7C68310, but the datasheet I used was the B rev, I think: <http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=14&rpn=CY7C68301B> Actually, the chip was labelled CY7C68310-80AC, but I couldn't tell if those last 4 digits were a version or just a datecode. > i test it as soon as i get my 68300A changed with the new -B- type > back from lab. Cool. > anyway, i see the first ATACB enabled (guaranteed) announced chip > should be the 683xxB types. maybe they have the correct behaviour > (16Bytes, opccode length problem), so maybe the last part of above > functionality could interfere. It shoudn't interfere, but it could be redundant. The length mod requires that the user set the correct CDB length in the SG_IO ioctl, which is how it was documented anyway. It is also how the sd and st drivers interpret the ioctl, so now at least that part is consistent between drivers. It would be better if they shared the code, though. I kind of doubt they've fixed their interface since I remember seeing the "24 24" opcode (as described in the B datasheet) being used on some Cypress chips at work 2 or 3 years ago, so it makes me think they've been consistent. An interesting note: the datasheet mentions that the 1st byte of the cdb comes from the EEPROM which means that when a board maker programs the chip they *could* pick a reasonable opcode (though the 2nd byte is still *required* to be 0x24, so the LUN issue still stands). -David - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
