]> err.no Git - linux-2.6/commit
[POWERPC] Define pci_unmap_addr() et al. when CONFIG_NOT_COHERENT_CACHE=y
authorRoland Dreier <rdreier@cisco.com>
Wed, 6 Dec 2006 23:15:38 +0000 (15:15 -0800)
committerPaul Mackerras <paulus@samba.org>
Fri, 8 Dec 2006 06:10:18 +0000 (17:10 +1100)
commit1d4454e7ce30239e67b154ae08f6d906b9737334
tree293946b4886a2b9cae9e70479cdd2ab678dd94c4
parent885ed0fb484cc2d0a539558edf47a2a7c4fdd664
[POWERPC] Define pci_unmap_addr() et al. when CONFIG_NOT_COHERENT_CACHE=y

The current PowerPC code makes pci_unmap_addr(), pci_unmap_addr_set(),
and friends trivial for all 32-bit kernels.  This is reasonable, since
for those kernels it is true that pci_unmap_single() does not need the
DMA address from the original DMA mapping -- in fact, it is a NOP.

However, I recently tried the tg3 driver on a PowerPC 440SPe machine,
which runs a 32-bit kernel and has non-cache-coherent PCI DMA.  I
found that the tg3 driver crashed in pci_dma_sync_single_for_cpu(),
since for non-coherent systems, that function must invalidate the
cache for the DMA address range requested, and therefore it does use
the address passed in.  tg3 uses a DMA address it stashes away with
pci_unmap_addr_set() and retrieves with pci_unmap_addr().  Of course,
since pci_unmap_addr() is defined to (0) right now, this doesn't work.

It seems to me that the tg3 driver is using pci_unmap_addr() in a
legitimate way -- I wouldn't want to have to teach all drivers that
they should use pci_unmap_addr() if they only need the address for
unmapping functions, but if they want the pci_dma_sync functions, then
they have to store the DMA address without the helper macros.
The right fix therefore seems to be in the definition of the macros in
<asm/pci.h> -- we should use the trivial versions only for 32-bit
kernels for coherent systems, and the real versions for both 64-bit
kernels and non-coherent systems.

Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
include/asm-powerpc/pci.h
include/asm-ppc/pci.h