Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Sun, 18 Aug 2013, Geert Uytterhoeven wrote:
On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann a...@arndb.de 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.
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
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann a...@arndb.de 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.
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)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
for (i = 0; i HCD_BUFFER_POOLS; i++) {
if (size = pool_max[i])
return dma_pool_alloc(hcd-pool[i], mem_flags, dma);
}
return dma_alloc_coherent(hcd-self.controller, size, dma, mem_flags);
}
which is called from usb_hcd_map_urb_for_dma():
if (hcd-self.uses_dma) {
} else if (hcd-driver-flags HCD_LOCAL_MEM) {
ret = hcd_alloc_coherent(
urb-dev-bus, mem_flags,
urb-setup_dma,
(void **)urb-setup_packet,
sizeof(struct usb_ctrlrequest),
DMA_TO_DEVICE);
...
}
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?
So I would change it to
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!bus-controller-dma_mask
!(hcd-driver-flags HCD_LOCAL_MEM))) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
Thanks for your clarification!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Thu, Jul 11, 2013 at 3:01 AM, Alan Stern st...@rowland.harvard.edu wrote:
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?
It won't. Unless the host driver itself calls into the DMA API, too
(are there any that don't?).
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?
Indeed.
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.
However, having the link errors helps when annotating the Kconfig files
with HAS_DMA dependencies.
Unfortunately the check for hcd-self.uses_dma (which boils down to
dev-dma_mask != NULL) isn't sufficient to cause breakage at compilation
time when a Kconfig entry incorrectly doesn't depend on HAS_DMA.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Thu, 11 Jul 2013, Geert Uytterhoeven wrote:
On Thu, Jul 11, 2013 at 3:01 AM, Alan Stern st...@rowland.harvard.edu wrote:
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?
It won't. Unless the host driver itself calls into the DMA API, too
(are there any that don't?).
To my knowledge, all the host controller drivers which use DMA _do_
call functions in the DMA API. So they would still get link errors,
even though the USB core wouldn't.
Therefore adding the appropriate HAS_DMA dependencies should be
straightforward: Try to build all the drivers and see which ones fail
to link.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: USB host support should depend on HAS_DMA
If NO_DMA=y: drivers/built-in.o: In function `usb_hcd_unmap_urb_setup_for_dma': drivers/usb/core/hcd.c:1361: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `usb_hcd_unmap_urb_for_dma': drivers/usb/core/hcd.c:1393: undefined reference to `dma_unmap_sg' drivers/usb/core/hcd.c:1398: undefined reference to `dma_unmap_page' drivers/usb/core/hcd.c:1403: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `usb_hcd_map_urb_for_dma': drivers/usb/core/hcd.c:1445: undefined reference to `dma_map_single' drivers/usb/core/hcd.c:1450: undefined reference to `dma_mapping_error' drivers/usb/core/hcd.c:1480: undefined reference to `dma_map_sg' drivers/usb/core/hcd.c:1495: undefined reference to `dma_map_page' drivers/usb/core/hcd.c:1501: undefined reference to `dma_mapping_error' drivers/usb/core/hcd.c:1507: undefined reference to `dma_map_single' drivers/usb/core/hcd.c:1512: undefined reference to `dma_mapping_error' drivers/built-in.o: In function `hcd_buffer_free': drivers/usb/core/buffer.c:146: undefined reference to `dma_pool_free' drivers/usb/core/buffer.c:150: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `hcd_buffer_destroy': drivers/usb/core/buffer.c:90: undefined reference to `dma_pool_destroy' drivers/built-in.o: In function `hcd_buffer_create': drivers/usb/core/buffer.c:65: undefined reference to `dma_pool_create' drivers/built-in.o: In function `hcd_buffer_alloc': drivers/usb/core/buffer.c:120: undefined reference to `dma_pool_alloc' drivers/usb/core/buffer.c:122: undefined reference to `dma_alloc_coherent' ,,, Commit d9ea21a779278da06d0cbe989594bf542ed213d7 (usb: host: make USB_ARCH_HAS_?HCI obsolete) allowed to enable USB on platforms with NO_DMA=y, and exposed several input and media USB drivers that just select USB if USB_ARCH_HAS_HCD, without checking HAS_DMA. Fix the former by making USB depend on HAS_DMA. To fix the latter, instead of adding lots of depends on HAS_DMA, make those drivers depend on USB, instead of depending on USB_ARCH_HAS_HCD and selecting USB. Drivers for other busses (e.g. MOUSE_SYNAPTICS_I2C) already handle this in a similar way. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/input/joystick/Kconfig|3 +-- drivers/input/misc/Kconfig| 15 +-- drivers/input/mouse/Kconfig |9 +++-- drivers/input/tablet/Kconfig | 15 +-- drivers/input/touchscreen/Kconfig |3 +-- drivers/media/rc/Kconfig | 21 +++-- drivers/usb/Kconfig |2 +- 7 files changed, 23 insertions(+), 45 deletions(-) diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig index 56eb471..d7e36fb 100644 --- a/drivers/input/joystick/Kconfig +++ b/drivers/input/joystick/Kconfig @@ -278,8 +278,7 @@ config JOYSTICK_JOYDUMP config JOYSTICK_XPAD tristate X-Box gamepad support - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use the X-Box pad with your computer. Make sure to say Y to Joystick support (CONFIG_INPUT_JOYDEV) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 0b541cd..00cdecb 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -286,8 +286,7 @@ config INPUT_ATLAS_BTNS config INPUT_ATI_REMOTE2 tristate ATI / Philips USB RF remote control - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use an ATI or Philips USB RF remote control. These are RF remotes with USB receivers. @@ -301,8 +300,7 @@ config INPUT_ATI_REMOTE2 config INPUT_KEYSPAN_REMOTE tristate Keyspan DMR USB remote control - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use a Keyspan DMR USB remote control. Currently only the UIA-11 type of receiver has been tested. The tag @@ -333,8 +331,7 @@ config INPUT_KXTJ9_POLLED_MODE config INPUT_POWERMATE tristate Griffin PowerMate and Contour Jog support - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use Griffin PowerMate or Contour Jog devices. These are aluminum dials which can measure clockwise and anticlockwise @@ -349,8 +346,7 @@ config INPUT_POWERMATE config INPUT_YEALINK tristate Yealink usb-p1k voip phone - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to enable keyboard and LCD functions of the Yealink usb-p1k usb phones. The audio part is enabled by the generic @@ -364,8 +360,7 @@ config INPUT_YEALINK config INPUT_CM109 tristate C-Media CM109 USB I/O Controller - depends on USB_ARCH_HAS_HCD - select USB + depends on USB
Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Wed, 10 Jul 2013, Geert Uytterhoeven wrote: If NO_DMA=y: drivers/built-in.o: In function `usb_hcd_unmap_urb_setup_for_dma': drivers/usb/core/hcd.c:1361: undefined reference to `dma_unmap_single' ,,, Commit d9ea21a779278da06d0cbe989594bf542ed213d7 (usb: host: make USB_ARCH_HAS_?HCI obsolete) allowed to enable USB on platforms with NO_DMA=y, and exposed several input and media USB drivers that just select USB if USB_ARCH_HAS_HCD, without checking HAS_DMA. Fix the former by making USB depend on HAS_DMA. 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. To fix the latter, instead of adding lots of depends on HAS_DMA, make those drivers depend on USB, instead of depending on USB_ARCH_HAS_HCD and selecting USB. Drivers for other busses (e.g. MOUSE_SYNAPTICS_I2C) already handle this in a similar way. That seems reasonable. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: USB host support should depend on HAS_DMA
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.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
