>Bad patch.  The devrequest struct needs to be in DMAable memory, and the
>kernels stack isn't DMAable on all arches.

>usb-storage is broken that way... it's on my TODO list, too...

>Matt

        Since my previous response to this message, I have now looked
through linux-2.5.1-pre8/Documentation/DMA-mapping.txt and the three
host controller drivers, and I now believe that my patch will work.

        All of the USB host controller drivers are PCI devices.
Apparently, they do not use the PC's DMA controller, and, therefore,
are not subject to its 16 megabyte address limit.

        It is true that, on some platforms, PCI devices are not
capable of accessing all of main memory, but Linux has a mechanism to
work avoid problem, and all of the USB host controller drivers already
use it (pci_{,un}map_single, etc.).  There seems to be no relationship
between what memory can be accessed by a PCI bus mastering device and
GFP_DMA.

        In the specific case of my patch, which would do a USB
transfer from the kernel stack, it looks like it is especially safe
because (if I have read the code correctly) the kernel stack comes
from alloc_task_struct(), which, in all existing architectures,
returns the a result from __get_free_pages(), and
Documentation/DMA-mapping.txt says:

|  If you acquired your memory via the page allocator
|  (i.e. __get_free_page*()) or the generic memory allocators
|  (i.e. kmalloc() or kmem_cache_alloc()) then you may DMA to/from
|  that memory using the addresses returned from those routines.

        By the way, it appears that the current x86 is arranged with
pci_{,un}map_single doing no address translation (that is, it assumes
that it is not given a >4GB address), and __get_free_pages always
returning a page below 4GB (i.e., not a HIGHMEM page).  Based on what
DMA-mapping.txt, I assume that if the behavior of __get_free_pages
were changed that pci_{,un}map_single would be changed accordingly.
(If you're dealing with a potentially highmem address, the routines
pci_{,un}map_page apparently provides similar functionality.)

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

Reply via email to