Re: [PATCH 02/02] sata_mv: workaround for multi_count errata sata24

[Mark Lord <liml@rtr.ca>]

Mark Lord wrote:
> Workaround for errata SATA#24 in sata_mv.
> This errata affects WRITE_MULTI* commands when
> the device multi_count produces a DRQ block size >= 4Kbytes.
> 
> We work around it here by converting such operations
> into ordinary PIO_WRITEs instead.
> 
> Note that this might result in a PIO FUA write unavoidably being converted
> into a non-FUA write.  In practice, any system using FUA is also going to be
> using DMA rather than PIO, so this shouldn't affect anyone in the real world.
..

Testing this was a real bear.

The drives I have here are among those which cannot do R/W MULTI
prior to having a SET_MULTIPLE command issued to them by libata.

Which libata currently does not do.

This means that libata is unable to cope with non-DMA devices
that report a non-zero multi_count value at startup.

I simulated this scenario in sata_mv by changing the .udma_mask field
to zero for the card under test.  System sat there retrying the
partition table read over and over and over and over..  :)

Someday I'll fix that, if you guys don't beat me to it.
I suppose we just need to issue the SET_MULTIPLE command from
the drive revalidation code.  

Cheers