Re: [PATCH] libata DMADIR support

[Jeff Garzik <jgarzik@pobox.com>]

Pat LaVarre wrote:
> My memory of my share of the SATA ATAPI UDMA flurry tells me that my Si
> 3611CT80 r1.4 bridge hangs with status = xD0 if we ask it to copy DMA
> Data In, without having prepared op xA0 "PACKET" features = x05 DMA In
> rather than x01 DMA Out.
> 
> Are you not convinced?

I am convinced that your hardware requires DMADIR.

I am not convinced that there is no way to detect this condition at 
runtime, based on some hardware characteristic, or output.



> I agree, by connecting my compliant only-DMADIR-capable bridge to a
> compliant PATA DMA device I have ended up violating ATA/PI 6 by claiming
> classic UDMA in op xA1 "IDENTIFY" "word" 88 (line 12 offset 0), when in
> fact the abomination I built only actually supports the DMADIR that
> ATA/PI 7 claims will be described in "word" 62 (line 7 offset 6).

Well, the expected behavior is proper implementation of word 62, bit 15 
at the very least :)

If hardware requires the DMADIR bit, it should set the feature bit that 
says "I require DMADIR".  If not, one could justifyably claim the 
hardware is not operating to spec.


> I imagine I was not the first and I will not be the last to fall into
> this spiked pit.  Particularly vulnerable will be the people who resell
> compliant PATA ATAPI UDMA devices and then fall into erroneously
> believing that adding a compliant SATA/PATA bridge makes a compliant
> SATA ATAPI UDMA device.

<shrug>  Honestly, I think the requirement of a data-direction bit was 
inevitable.  I'm surprised you don't have one for ATA devices. 
Consider:  what data direction will a vendor-reserved SCSI opcode 
require?  The OS driver cannot know.

If you accept that premise, then these changes to ATA were required...

	Jeff