libata: Fix a large collection of DMA mode mismatches
authorAlan Cox <alan@redhat.com>
Fri, 1 Aug 2008 08:18:34 +0000 (09:18 +0100)
committerJeff Garzik <jgarzik@redhat.com>
Fri, 22 Aug 2008 06:27:49 +0000 (02:27 -0400)
commitb15b3ebae102f89c25ccbcae0b2099af312f2e82
tree73f64d0e578d1c6bc6a3dc43f940a31f24daad8f
parent20e2de4a505aa02131a95665e8920eb053fce686
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>
drivers/ata/libata-core.c
drivers/ata/pata_acpi.c
drivers/ata/pata_atiixp.c
drivers/ata/pata_cs5530.c
drivers/ata/pata_oldpiix.c
drivers/ata/pata_sc1200.c
include/linux/libata.h