[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1307102054340.11279-100000@netrider.rowland.org>
Date: Wed, 10 Jul 2013 21:01:31 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Arnd Bergmann <arnd@...db.de>
cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
<linux-input@...r.kernel.org>, <linux-media@...r.kernel.org>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Thu, 11 Jul 2013, Arnd Bergmann wrote:
> On Wednesday 10 July 2013, Alan Stern wrote:
> > 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.
How will it give link errors for drivers that require DMA?
Besides, wouldn't it be better to get an error at config time rather
than at link time? Or even better still, not to be allowed to
configure drivers that depend on DMA if DMA isn't available?
If we add an explicit dependency for HAS_DMA to the Kconfig entries for
these drivers, then your suggestion would be a good way to allow
usbcore to be built independently of DMA support.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists