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>
This commit is contained in:
@@ -167,10 +167,10 @@ static unsigned int sc1200_qc_issue(struct ata_queued_cmd *qc)
|
||||
struct ata_device *prev = ap->private_data;
|
||||
|
||||
/* See if the DMA settings could be wrong */
|
||||
if (adev->dma_mode != 0 && adev != prev && prev != NULL) {
|
||||
if (ata_dma_enabled(adev) && adev != prev && prev != NULL) {
|
||||
/* Maybe, but do the channels match MWDMA/UDMA ? */
|
||||
if ((adev->dma_mode >= XFER_UDMA_0 && prev->dma_mode < XFER_UDMA_0) ||
|
||||
(adev->dma_mode < XFER_UDMA_0 && prev->dma_mode >= XFER_UDMA_0))
|
||||
if ((ata_using_udma(adev) && !ata_using_udma(prev)) ||
|
||||
(ata_using_udma(prev) && !ata_using_udma(adev)))
|
||||
/* Switch the mode bits */
|
||||
sc1200_set_dmamode(ap, adev);
|
||||
}
|
||||
|
Reference in New Issue
Block a user