On Apr 21, 2010, at 9:09, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
On Wed, 21 Apr 2010, Luben Tuikov wrote:
The Sector Count field in the ATA PASS-THROUGH (12) or (16) CDB
should be set appropriately by the Application Client as the neither
the SAT bridge nor the SATA transport will interpret the ATA Command
byte. Thus, for IDENTIFY (PACKET) DEVICE the Application Client
should set it to 1.
Why do you say that 1 is the appropriate value? In the ATA-5 spec
(which is the most recent version I have) Sector Count is listed as
"na" for IDENTIFY DEVICE, which means that the content of that field is
not applicable to this particular command. Hence the value shouldn't
matter.
It is needed by the transport protocol(s).
I don't understand; can you explain more fully? Which transport
protocol(s) need to use the Sector Count? The USB transport protocol
doesn't; it encodes the transfer length in a wrapper. The bridge chip
should interpret the wrapper instead of looking inside the SAT command.
Well BOT is the exception. In general transports aren't concerned with the size, etc of the command. They just transport the CDB. UAS for example, being in SAM-spirit transport and in this sense being mature over BOT.
The transfer length is part of the CDB, if the command is expected to transfer data and ATA PT CDBs are no exception. The transport bridge would "convert" from one transport protocol into another and it thus need to know the transfer size if any to prep the next protocol for the command. In this case this is visualized as UAS(SCSI)<-->SATA(ATA). Use BOT, wlg.
This is really the function of SAT. Unknown CDBs are treated as bi-directional to let the target determine data transfer direction if any.
Luben
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
