[lkml]   [2010]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: USB transfer_buffer allocations on 64bit systems
    On Wed, 7 Apr 2010, Greg KH wrote:

    > Yeah, I really don't want to have to change every driver in different
    > ways just depending on if someone thinks it is going to need to run on
    > this wierd hardware.

    It's not weird hardware, as far as I know. It's just a 64-bit system
    with a 32-bit USB host controller.

    (And remember, while there are 64-bit EHCI controllers, there are not
    any 64-bit OHCI or UHCI controllers. So whenever somebody plugs a
    full-speed or low-speed device into a 64-bit machine, they will face
    this problem. It's like the old problem of ISA devices that could
    only do DMA to addresses in the first 16 MB of memory -- what the
    original GFP_DMA flag was intended for.)

    > Alan, any objection to just using usb_buffer_alloc() for every driver?
    > Or is that too much overhead?

    I don't know what the overhead is. But usb_buffer_alloc() requires the
    caller to keep track of the buffer's DMA address, so it's not a simple
    plug-in replacement. In addition, the consistent memory that
    usb_buffer_alloc() provides is a scarce resource on some platforms.

    Writing new functions is the way to go.

    Alan Stern

     \ /
      Last update: 2010-04-07 17:57    [W:0.020 / U:18.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site