Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758139Ab0DGTNN (ORCPT ); Wed, 7 Apr 2010 15:13:13 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:43275 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1757216Ab0DGTNM (ORCPT ); Wed, 7 Apr 2010 15:13:12 -0400 Date: Wed, 7 Apr 2010 15:13:11 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Takashi Iwai cc: Daniel Mack , Greg KH , , Pedro Ribeiro , , Greg KH , , Subject: Re: USB transfer_buffer allocations on 64bit systems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2272 Lines: 62 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"); #endif } 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. Note also that just before the lines above, ehci-hcd.c contains this comment: * pci_pool consistent memory always uses segment zero. (Nowadays the driver uses dma_pool, not pci_pool.) As far as I can tell, this comment isn't true on 64-bit systems, but nevertheless, ehci-hcd relies on it. Of course it _is_ true for devices whose DMA mask indicates they can't use memory above 4 GB -- but if ehci-hcd is changed to enlarge the DMA mask then how do we force dma_pool memory to lie below 4 GB? [Actually it isn't _really_ necessary for the dma_pool to lie below 4 GB. But ehci-hcd allocates several pools, and it _is_ necessary for all of them to lie in the _same_ 4 GB segment. The easiest way to do that is to put them all in segment 0.] Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/