summaryrefslogtreecommitdiffstats
path: root/drivers/ata/pata_atiixp.c
diff options
context:
space:
mode:
authorAlan Cox <alan@redhat.com>2008-08-01 09:18:34 +0100
committerJeff Garzik <jgarzik@redhat.com>2008-08-22 02:27:49 -0400
commitb15b3ebae102f89c25ccbcae0b2099af312f2e82 (patch)
tree73f64d0e578d1c6bc6a3dc43f940a31f24daad8f /drivers/ata/pata_atiixp.c
parent20e2de4a505aa02131a95665e8920eb053fce686 (diff)
downloadop-kernel-dev-b15b3ebae102f89c25ccbcae0b2099af312f2e82.zip
op-kernel-dev-b15b3ebae102f89c25ccbcae0b2099af312f2e82.tar.gz
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>
Diffstat (limited to 'drivers/ata/pata_atiixp.c')
-rw-r--r--drivers/ata/pata_atiixp.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
index d7de7ba..e8a0d99 100644
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -183,7 +183,7 @@ static void atiixp_bmdma_start(struct ata_queued_cmd *qc)
u16 tmp16;
pci_read_config_word(pdev, ATIIXP_IDE_UDMA_CONTROL, &tmp16);
- if (adev->dma_mode >= XFER_UDMA_0)
+ if (ata_using_udma(adev))
tmp16 |= (1 << dn);
else
tmp16 &= ~(1 << dn);
OpenPOWER on IntegriCloud