On Sun, 18 Aug 2013, Geert Uytterhoeven wrote:

On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann [off-list ref] wrote:

quoted

On Wednesday 10 July 2013, Alan Stern wrote:

quoted

This isn't right.  There are USB host controllers that use PIO, not
DMA.  The HAS_DMA dependency should go with the controller driver, not
the USB core.

On the other hand, the USB core does call various routines like
dma_unmap_single.  It ought to be possible to compile these calls even
when DMA isn't enabled.  That is, they should be defined as do-nothing
stubs.

The asm-generic/dma-mapping-broken.h file intentionally causes link
errors, but that could be changed.

The better approach in my mind would be to replace code like


        if (hcd->self.uses_dma)

with

        if (IS_ENABLED(CONFIG_HAS_DMA) && hcd->self.uses_dma) {

which will reliably cause that reference to be omitted from object code,
but not stop giving link errors for drivers that actually require
DMA.

This can be done for drivers/usb/core/hcd.c.

But I'm a bit puzzled by drivers/usb/core/buffer.c. E.g.

void *hcd_buffer_alloc(...)
{
        ....
        /* some USB hosts just use PIO */
        if (!bus->controller->dma_mask &&
            !(hcd->driver->flags & HCD_LOCAL_MEM)) {

I don't remember the full story.  You should check with the person who
added the HCD_LOCAL_MEM flag originally.

So if DMA is not used (!hcd->self.uses_dma, i.e. bus->controller->dma_mask
is zero), and HCD_LOCAL_MEM is set, we still end up calling dma_pool_alloc()?

(Naively, I'm not so familiar with the USB code) I'd expect it to use
kmalloc() instead?

Maybe what happens in this case is that some sort of hook causes the 
allocation to be made from a special memory-mapped region on board the 
controller.

Alan Stern