libata: fix ata_dma_enabled
PATCH 1/1 libata: fix ata_dma_enabled
ata_dma_enabled should check if device is either using multi word DMA or ultra DMA instead of checking 0xff, as dma_mode 0 is not a valid dma mode either.
This patch fixes the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=49151
--- include/linux/libata.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/libata.h +1 -1
@@ -1617,7 +1617,7 @@ static inline int ata_using_udma(struct ata_device *adev)static inline int ata_dma_enabled (struct ata_device *adev) { -return (adev->dma_mode ==0xFF ?0 :1 ); +return ata_using_mwdma (adev) ||ata_using_udma (adev); }/**************************************************************************
Signature · 1 line
1.8.0.1.2.gd1eded4
Alan Cox
NAKQuoted 7 lines · On Mon, 03 Dec 2012 09:04:20 +0800 Aaron Lu <[email protected]> wrote:
ata_dma_enabledshould check if device is either using multi word DMA or ultra DMA instead of checking0xff, asdma_mode0 is not a valid dma mode either.This patch fixes the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=49151
NAK
dma_mode should *NEVER* be zero. If it's getting set to zero you have another bug and that needs fixing instead
Alan
Quoted 8 lines · Alan Cox
Quoted 5 lines · On Mon, 03 Dec 2012 09:04:20 +0800 Aaron Lu <[email protected]> wrote:
ata_dma_enabledshould check if device is either using multi word DMA or ultra DMA instead of checking0xff, asdma_mode0 is not a valid dma mode either.
Quoted 7 lines
Quoted 2 lines
This patch fixes the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=49151NAK
dma_modeshould *NEVER* be zero. If it's getting set to zero you have another bug and that needs fixing instead
The ata_dev->dma_mode is initialized as zero after we allocate the ata_device structure, and we did not set this field until the set mode function.
If you think it should _never_ be zero, probably my previous patch did the job: it sets ata_dev->dma_mode to 0xff in the reset operation:
drivers/ata/libata-eh.c +1 -0
@@ -2657,6 +2657,7 @@ int ata_eh_reset(struct ata_link *link, int classify,* bus as we may be talking too fast. */ dev->pio_mode =XFER_PIO_0 ; + dev->dma_mode =0xff ;/* If the controller has a pio mode setup function * then use it to set the chipset to rights. Don't
So do you prefer this?
Thanks,
Aaron
Quoted 2 lines
Alan
Quoted 14 lines
drivers/ata/libata-eh.c +1
-0@@ -2657,6 +2657,7 @@ int ata_eh_reset(struct ata_link *link, int classify,* bus as we may be talking too fast. */ dev->pio_mode =XFER_PIO_0 ; + dev->dma_mode =0xff ;/* If the controller has a pio mode setup function * then use it to set the chipset to rights. Don't
Quoted 1 line
So do you prefer this?
Yes - definitely. That is the intended behaviour.
PATCH 1/1 libata: set dma_mode to 0xff in reset
In reply to Aaron Luata_device->dma_mode's initial value is zero, which is not a valid dma mode, but ata_dma_enabled will return true for this value. This patch sets dma_mode to 0xff in reset function, so that ata_dma_enabled will not return true for this case, or it will cause problem for pata_acpi.
The corrsponding bugzilla page is at:
https://bugzilla.kernel.org/show_bug.cgi?id=49151
--- drivers/ata/libata-core.c | 1 + drivers/ata/libata-eh.c | 1 + 2 files changed, 2 insertions(+)
drivers/ata/libata-core.c +1 -0
@@ -2560,6 +2560,7 @@ int ata_bus_probe(struct ata_port *ap)* bus as we may be talking too fast. */ dev->pio_mode =XFER_PIO_0 ; + dev->dma_mode =0xff ;/* If the controller has a pio mode setup function * then use it to set the chipset to rights. Don't
drivers/ata/libata-eh.c +1 -0
@@ -2657,6 +2657,7 @@ int ata_eh_reset(struct ata_link *link, int classify,* bus as we may be talking too fast. */ dev->pio_mode =XFER_PIO_0 ; + dev->dma_mode =0xff ;/* If the controller has a pio mode setup function * then use it to set the chipset to rights. Don't
Signature · 1 line
1.7.12.4
Re: [PATCH] libata: set dma_mode to 0xff in reset
Quoted 11 lines · On Mon, 03 Dec 2012 11:35:02 +0800 Aaron Lu <[email protected]> wrote:
ata_device->dma_mode's initial value is zero, which is not a valid dma mode, but
ata_dma_enabledwill return true for this value. This patch setsdma_modeto0xffin reset function, so thatata_dma_enabledwill not return true for this case, or it will cause problem forpata_acpi.The corrsponding bugzilla page is at:
https://bugzilla.kernel.org/show_bug.cgi?id=49151Reported-by Phillip Wood <[email protected]>Signed-off-by Aaron Lu <[email protected]>
Jeff Garzik
AppliedRe: [PATCH] libata: set dma_mode to 0xff in reset
In reply to Aaron LuQuoted 14 lines · Aaron Lu
ata_device->dma_mode's initial value is zero, which is not a valid dma mode, but
ata_dma_enabledwill return true for this value. This patch setsdma_modeto0xffin reset function, so thatata_dma_enabledwill not return true for this case, or it will cause problem forpata_acpi.The corrsponding bugzilla page is at:
https://bugzilla.kernel.org/show_bug.cgi?id=49151Reported-by Phillip Wood <[email protected]>Signed-off-by Aaron Lu <[email protected]>Tested-by Szymon Janc <[email protected]>Tested-by Dutra Julio <[email protected]>Cc <[email protected]>
Quoted 4 lines
--- drivers/ata/libata-core.c | 1 + drivers/ata/libata-eh.c | 1 + 2 files changed, 2 insertions(+)
applied