Re: alpha iommu fixes

[David S. Miller]

Andrea Arcangeli writes:
 > On Sun, May 20, 2001 at 06:01:40PM -0700, David S. Miller wrote:
 > > No, the interface says that the DMA routines may not return failure.
 > 
 > The alpha returns a faliure since day zero of iommu support, the sparc64
 > has too otherwise it's even more buggy than alpha when the machine runs
 > out of pci virtual address space.

So what?  I frankly don't care what alpha or any platform happens to
do.  The Documentation/DMA-mapping.txt document says absolutely
nothing about these routines ever failing nor what a failure value
would be.  If you ask David Mosberger and the ia64 people, the PPC
folks, or even HPPA port team, they will all show no surprise when
told that these routines may not fail.  I talked to them, along with
Richard, about this issue at length when the DMA stuff was put
together.  And it was agreed upon that the routines will not allow
failure in 2.4.x and we would work on resolving this in 2.5.x and no
sooner.

THIS DMA-mapping.txt document is the specification of the behavior of
these DMA interfaces, and the driver author may only assume the
behavior described in that document.

If Alpha does something different, that's a feature.

 > About the pci_map_single API I'd like if bus address 0 would not be the
 > indication of faluire, mainly on platforms without an iommu that's not
 > nice, x86 happens to get it right only because the physical page zero is
 > reserved for completly other reasons. so we either add a err parameter
 > to the pci_map_single, or we define a per-arch bus address to indicate
 > an error, either ways are ok from my part.

I'm more than happy to add the per-arch define (which would be zero
on all platforms right now, so this exercise is %100 academic :-)))))

But I will NOT add the change that the pci_map_*() interfaces may
fail in 2.4.x, this is an unacceptable API change.  Reasons are
starting with the scsi layer issues Gerard mentioned, and I knew
about this kind of crap when I designed the API.  We can work on a
failure mode for this stuff, but it is 2.5.x material, no sooner.

Later,
David S. Miller
[e-mail]