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 

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

--

[ message continues ]

Ok, I'll write some dummies for usb_malloc() and usb_zalloc() which
will just call kmalloc() with GFP_DMA32 for now. And while at it,
usb_alloc_buffer() will be renamed to usb_alloc_consistent(). Then I'll
try to clean up all existing drivers to use this new interface and
follow the changes.

In a next step, we should fine-tune when GFP_DMA32 is really needed.
And I'll leave all occurances of usb_alloc_consistent() as they are now.

Does that sound ok?

Thanks,
Daniel

--

[ message continues ]

At Wed, 7 Apr 2010 18:16:03 +0200,

Can't we provide only zalloc() variant?  Zero'ing doesn't cost much,

Most of recent functions are named with "coherent".


thanks,

Takashi
--

[ message continues ]

I agree to both points, will do so unless anyone has a harsh opinion
about that.

Another thing: I guess we don't need a corresponding free() function
that just calls kfree(), right? Or should we introduce it now to be
flexible for future extensions?

Daniel

--

[ message continues ]

At Wed, 7 Apr 2010 19:59:35 +0200,

Well, I would implement the corresponding free.  It could be simply
a macro calling kfree(), but it's saner to provide it for API
uniformity, IMO.


thanks,

Takashi
--

[ message continues ]

At Wed, 7 Apr 2010 11:55:19 -0400 (EDT),

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
--

[ message continues ]