Re: [PATCH] libata: fix ATA passthrough handling for ATAPI devices

[Douglas Gilbert <dougg@torque.net>]

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