At Wed, 7 Apr 2010 11:55:19 -0400 (EDT), Alan Stern wrote:
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.
Yeah, also the area is aligned to kernel pages, and it may be much bigger than the requested (power-of-two). If not needed, we should avoid it.
thanks,
Takashi