Jeff Garzik wrote: > Douglas Gilbert wrote: >> Jeff Garzik wrote: >>> I'm talking about the changes to the implementation, which appear to >>> mistakenly allow 16-byte CDBs through to the ATAPI device, even if it >>> only supports 12-byte CDBs. >>> >>> I am quite aware of the ATA passthru SCSI command. Heck, the spec had >>> input from me. I'm talking about something different. > >> The above were attempts to send IDENTIFY PACKET DEVICE >> to the PATAPI cd/dvd drive via the ATA PASS THROUGH >> (16 and 12) commands respectively. The first one caught >> my attention. Why did it fail with a DID_ABORT? >> >> Whatever the reason both responses are wrong. The second >> one is wrong because >> - the cd/dvd drive does support that opcode (the error >> should be either not ready or incompatible format), or >> - it didn't do the ATA PASS THROUGH (12) properly > > The thread has moved on from discussing the acknowledged problem to > discussing the solution. > > To summarize my quoted email above, I'm talking about problems with the > implementation details. There are two engineering constraints which a > solution must not violate: > 1) The kernel must prevent 16-byte non-passthru commands from reaching > 12-byte-only ATAPI devices. I would prefer to see the command sent through until it hits a transport that cannot carry a 16 byte cdb. That transport may be in an external enclosure, or the limitation may have been removed. > 2) Existing in-the-field solutions that issue commands such as BLANK or > a vendor-reserved 0x85 opcode must continue working, without recompile. Opcodes 0x85 and 0xa1 are not vendor reserved. They have been reserved for t10.org use since SCSI-2. Other SCSI opcode ranges are set aside for vendor use. The BLANK problems remains. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
