Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Thu, Jan 25, 2007 at 11:17:20AM -0500, Jeff Garzik wrote:
> David Woodhouse wrote:
> >On Thu, 2007-01-25 at 15:09 +0000, Alan wrote:
> >>diff -u --new-file --recursive --exclude-from /usr/src/exclude 
> >>linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c 
> >>linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
> >>--- linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c       
> >>2007-01-22 16:26:50.000000000 +0000
> >>+++ linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c       2007-01-24 
> >>17:31:40.000000000 +0000
> >>@@ -827,7 +827,8 @@
> >>  */
> >> void ata_bmdma_post_internal_cmd(struct ata_queued_cmd *qc)
> >> {
> >>-       ata_bmdma_stop(qc);
> >>+       if (qc->ap->ioaddr.bmdma_addr)
> >>+               ata_bmdma_stop(qc);
> >> }
> >
> >But what if the bmdma_addr _is_ zero? Please, let's not allow the "zero
> >is not a valid number" braindamage to spread any further than the IRQ
> >setup it's already broken.
> 
> Read the code...  This test is already widely in use in libata.

Ditto.  The only interpretation that can be placed upon DMA addresses
is done by dma_mapping_error(), which _is_ a per-architecture defined
test because these things aren't defined in the API.

The zero DMA address is absolutely and totally valid.  It might not
correspond with physical address zero on platforms.

Also, DMA address zero is not the same as NULL.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: