Re: USB transfer_buffer allocations on 64bit systems

From: Robert Hancock
Date: Wed Apr 07 2010 - 19:59:37 EST

On 04/07/2010 01:13 PM, Alan Stern wrote:
On Wed, 7 Apr 2010, Takashi Iwai wrote:

Ok, I'll write some dummies for usb_malloc() and usb_zalloc() which
will just call kmalloc() with GFP_DMA32 for now.

Can't we provide only zalloc() variant? Zero'ing doesn't cost much,
and the buffer allocation shouldn't be called too often.

Linus specifically requested us to avoid using kzalloc in usbfs. I
can't find the message in the email archives, but Greg KH should be
able to confirm it.

As long as we're imitating kmalloc for one use, we might as well make
it available to all.

And while at it,
usb_alloc_buffer() will be renamed to usb_alloc_consistent().

Most of recent functions are named with "coherent".

Yes, the terminology got a little confused between the PCI and DMA
realms. I agree, "coherent" is better.

BTW, although some EHCI controllers may support 64-bit DMA, the driver
contains this:

if (HCC_64BIT_ADDR(hcc_params)) {
ehci_writel(ehci, 0,&ehci->regs->segment);
#if 0
// this is deeply broken on almost all architectures
if (!dma_set_mask(hcd->self.controller, DMA_BIT_MASK(64)))
ehci_info(ehci, "enabled 64bit DMA\n");

I don't know if the comment is still true, but until the "#if 0" is
removed, ehci-hcd won't make use of 64-bit DMA.

The comment is wrong (or at least outdated or based on an incorrect assumption), but you're right, currently 64-bit DMA is not used on any EHCI controllers. It could be, but it sounded like the consensus was it wasn't worth the risk. Apparently Windows 7 started using it, and then had to put out a patch because some NVidia EHCI controllers indicated 64-bit support but it didn't work properly. So you'd have to blacklist those controllers, at least.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at