>> 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
linux-2.5.1-pre8/include/asm-i386/processor.h defines
alloc_task_struct to call __get_free_pages *without* __GFP_HIGHMEM
set. So, I believe the stack will always be allocated from pages
below 4GB.
>> [...] 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 (the PCI drivers and a statement
about a USB driver for SuperH) and ask for an example of a problem.
I've checked the PCI drivers; the SuperH device is apparently on the
processor core, so it is quite unlikely that it would be unable to
drive any of the high address lines. So, all I can do is invite
people to point out a real example and investigate. In practice, all
USB controllers seem to be implimentations of {O,U,E}HCI, which is
based on bus mastering rather than using a PC's DMA controller, and
the controllers are either PCI devices or are embedded on the CPU
or motherboard chipset.
>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).
>> 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
Theoretically, pci_{,un}map_single's spec is that it should
handle this (presuamably by copying the data). In practice, I don't
want to incur the performance cost of pci_{,un}map_single thinking
about that.
I think the ways to avoid this are simple enough to make USB
transfers from kernel stack and data still worth doing, but thanks for
raising this interesting point which I had not thought of. For
example, since the problem that you suggest is also potentially
applicable to the kernel stack, it means that I would have to change
my patch to usb_control_cmd in drivers/usb/usb.c to ensure 8 byte
alignment, which may not be worth it, given that it is a routine that
I want to eliminate eventually. There are other cases (which currently
call usb_control_cmd), where I think I would want to still have the
performance benefit of using the stack rather than kmalloc/kfree.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
