This message is from the T13 list server.
Doc 04-262r1 gets my vote of approval.
Major comments:
* when a SET FEATURES - XFER MODE command is issued, any bridge / OS driver is -STRONGLY ADVISED- to perform implementation-specific actions necessary to accomodate the command [such as reprogramming controller PIO or DMA timings]
* perhaps mention somewhere that command protocol, if specified MUST [using RFC language] be correct with regards to the command opcode. i.e. it should be a spec violation for the application to specify a READ DMA opcode but a PIO-In protocol. Behavior in that case is defined as undefined :)
Minor comments:
* I prefer my list of command protocols, because the list is more abstract and transport-independent. More "future-proof."
* similarly, if one to pursue the idea of abstraction, it would be nice to have three bits: host-reset, bus-reset, and device-reset. rather than HWRST.
* (regarding command protocol) "Bridges that do not implement this field may not be able to execute queued commands." I would add mention of similar limitation in execution of vendor-reserved commands
* why separate protocols for pio-{in,out} and udma-{in,out} when you have a separate bit for data direction?
* in practice DMA in/out and udma in/out are the same
* is the DMA bit needed any longer?
