libata: Fix a large collection of DMA mode mismatches

Dave Müller sent a diff for the pata_oldpiix that highlighted a problem
where a lot of the ATA drivers assume dma_mode == 0 means "no DMA" while
the core code uses 0xFF.

This turns out to have other consequences such as code doing >= XFER_UDMA_0
also catching 0xFF as UDMAlots. Fortunately it doesn't generally affect
set_dma_mode, although some drivers call back into their own set mode code
from other points.

Having been through the drivers I've added helpers for using_udma/using_mwdma
dma_enabled so that people don't open code ranges that may change (eg if UDMA8
appears somewhere)

Thanks to David for the initial bits
[and added fix for pata_oldpiix from and signed-off-by Dave Mueller
 <dave.mueller@gmx.ch>  -jg]

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>

1 files changed, 2 insertions, 2 deletions

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 5f8f57a818fb..79e3a8e7a84a 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3288,7 +3288,7 @@ int ata_do_set_mode(struct ata_link *link, struct ata_device **r_failed_dev)
                 dev->dma_mode = ata_xfer_mask2mode(dma_mask);
 
                 found = 1;
-                if (dev->dma_mode != 0xff)
+                if (ata_dma_enabled(dev))
                         used_dma = 1;
         }
         if (!found)
@@ -3313,7 +3313,7 @@ int ata_do_set_mode(struct ata_link *link, struct ata_device **r_failed_dev)
 
         /* step 3: set host DMA timings */
         ata_link_for_each_dev(dev, link) {
-                if (!ata_dev_enabled(dev) || dev->dma_mode == 0xff)
+                if (!ata_dev_enabled(dev) || !ata_dma_enabled(dev))
                         continue;
 
                 dev->xfer_mode = dev->dma_mode;