Messages in this thread | | | From | "David S. Miller" <> | Date | Mon, 21 May 2001 00:05:40 -0700 (PDT) | Subject | Re: alpha iommu fixes |
| |
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 davem@redhat.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |