> pci_{,un}map_single, so they should work. I suspect all real non-PCI
> USB controllers are either on a bus that can access all main memory or
> are specific to an architecture that is known to allocate the kernel
Wrong already. x86 with more than 4Gb of memory
> controllers (i.e., usually PCI). Kernel stacks are typically only
> 4kB, and there are typically only 100 or so processes. Even on a
8-16K
> the control pipe, not just USB). These busses are getting much faster
> relative to CPU's and their performance is becoming more of an issue
> as people put more demanding hardware across them, like disk, network,
> and digital video. I think this usage is common enough and important
> enough that its worth optimizing some kernel programming interfaces
> for it, especially since all architectures currently appear to support
> this optimization anyhow.
I've seen no evidence of this. None at all.
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.
> have the CPU read it. This requires pointing the USB controllers at
> kernel read only data. For packets that have to be computed at run
kernel read only data in a module is vmalloc space. Your data might even be
split across two pages
> 1. Identify one real hardware configuration where the USB
> controller cannot read the kernel stack or kernel read-only
IBM PC
Alan
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
