> >> [...] all architectures currently appear to support > >> [DMA from kernel stack] anyhow. > > >I've seen no evidence of this. None at all. > > You're asking me to prove a negative, which I can only do by > looking at the instances available ...
Or asking the folk who've had to deal with such issues. While I've mostly worked with Linux on x86 systems, some folk discussing non-PCI OHCI patches with me have reported DMA limitations like "must be in first MByte". (I think that was an ARM CPU, not MIPS or PPC.) Doesn't seem to me like systems with issues like that will waste that valuable MByte of space on kernel stacks. > >The DMA mapping document also says > > >| This rule also means that you may not use kernel image addresses > >| (ie. items in the kernel's data/text/bss segment, or your driver's) > >| nor may you use kernel stack addresses for DMA. Both of these items > >| might be mapped somewhere entirely different than the rest of physical > >| memory. > > The USB drivers do not DMA from those values directly. They > DMA from the result of pci_map_single, which is supposed to handle > that remapping on architectures that require it (and just returns the > address on the architectures where no remapping is required). Nope ... those routines demand inputs that meet the rule Alan described: allocated with kmalloc/friends, not vmalloc. If some code wants to take vmalloc memory and do I/O with it, the solution gets complicated. In principle one must pin pages and pass their "real" addreses to an I/O layer. That gets into the VM and block I/O layers ... less stable than USB! :) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
