[t13] T10/04-262r0

Jeff Garzik jgarzik at pobox.com
Thu Aug 12 16:04:22 PDT 2004

* From the T10 Reflector (t10 at t10.org), posted by:
* Jeff Garzik <jgarzik at pobox.com>
Marushak, Nathan wrote:
> I'm not sure I follow the need to specify the protocol.  The assumption
> is we are passing through an ATA command to an ATA controller.  As such,
> the "cumbersome (and unneeded) table or switch statement" has always
> gone with the ATA controller.  Somebody has to perform the lookup to go
> from command type to the sequence type (data protocol), whether it be at
> the highest level, lowest level, or somewhere in between.

Certainly.  Otherwise it would be impossible to execute vendor-reserved 

Given that the protocol is unknown for vendor-reserved commands, it 
follows that one must specify the protocol for vendor-reserved commands.

If one must specify the protocol in some cases, it then follows that the 
most efficient OS driver implementation is to require specification in 
ALL cases, thereby avoiding the lookup table / switch statement completely.

> As far as vendor unique commands...good question.  ATA Controllers have
> to understand that the command being passed to them is vendor unique.
> Understanding the command is vendor unique, then the controller won't
> make any assumptions about subsequent packets.  Basically it will wait
> until it receives signals or FISes back from the target before
> understanding what the data protocol might be or what the next step is.
> I believe this is true in all cases.
> Suffice to say, I don't believe the existing ATA controllers on the
> market require knowledge of each and every vendor unique command for
> each and every target on the market, yet they do still allow for vendor
> unique commands.

> To summarize, I don't see the need to specify a data protocol since
> there currently is no need to specify data protocol in a SATA Register
> FIS.

Please look at how ultra-modern SATA controllers support vendor reserved 
commands ;-)

* Some vendors have a 'command protocol' field that must be filled in 
for each command issued.

* Some vendors have special 'vendor command setup' commands, snooped by 
the host controller, which specify this information to the host controller.

* A few vendors with bridged SATA implementations simply don't support 
vendor reserved commands at all, because it is impossible to 'tell' the 
controller the FIS protocol.

* The remaining vendors seem to have chosen to allow direct control over 
FIS transmission/reception by the low-level driver, so that the driver 
may ensure that the command protocol is followed for the cases where the 
host controller silicon / firmware doesn't know how to handle the command.

The people actually making the controllers recognized the need to allow 
the OS driver to specify the data protocol, precisely because it is 
_impossible_ to know the protocol in all cases.

I have recognized this requirement, and have implemented this for the 
following vendor's controllers, where possible:  Intel, Silicon Image, 
Marvell, Promise, Vitesse, VIA, SiS, and Broadcom/ServerWorks.


* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list