| Message ID | 1373491112-15593-1-git-send-email-geert@linux-m68k.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 11, 2013 at 3:01 AM, Alan Stern <stern@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 -- geert@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-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 11 Jul 2013, Geert Uytterhoeven wrote: > On Thu, Jul 11, 2013 at 3:01 AM, Alan Stern <stern@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-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann <arnd@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 -- geert@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-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 18 Aug 2013, Geert Uytterhoeven wrote: > On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann <arnd@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-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 help Say Y here if you want to enable keyboard and buzzer functions of the C-Media CM109 usb phones. The audio part is enabled by the generic diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig index effa9c5..90f8c0b 100644 --- a/drivers/input/mouse/Kconfig +++ b/drivers/input/mouse/Kconfig @@ -161,8 +161,7 @@ config MOUSE_SERIAL config MOUSE_APPLETOUCH tristate "Apple USB Touchpad support" - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use an Apple USB Touchpad. @@ -182,8 +181,7 @@ config MOUSE_APPLETOUCH config MOUSE_BCM5974 tristate "Apple USB BCM5974 Multitouch trackpad support" - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you have an Apple USB BCM5974 Multitouch trackpad. @@ -346,8 +344,7 @@ config MOUSE_SYNAPTICS_I2C config MOUSE_SYNAPTICS_USB tristate "Synaptics USB device support" - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use a Synaptics USB touchpad or pointing stick. diff --git a/drivers/input/tablet/Kconfig b/drivers/input/tablet/Kconfig index bed7cbf..8e27600 100644 --- a/drivers/input/tablet/Kconfig +++ b/drivers/input/tablet/Kconfig @@ -13,8 +13,7 @@ if INPUT_TABLET config TABLET_USB_ACECAD tristate "Acecad Flair tablet support (USB)" - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use the USB version of the Acecad Flair tablet. Make sure to say Y to "Mouse support" @@ -26,8 +25,7 @@ config TABLET_USB_ACECAD config TABLET_USB_AIPTEK tristate "Aiptek 6000U/8000U and Genius G_PEN tablet support (USB)" - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use the USB version of the Aiptek 6000U, Aiptek 8000U or Genius G-PEN 560 tablet. Make sure to say Y to @@ -51,8 +49,7 @@ config TABLET_USB_GTCO config TABLET_USB_HANWANG tristate "Hanwang Art Master III tablet support (USB)" - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use the USB version of the Hanwang Art Master III tablet. @@ -62,8 +59,7 @@ config TABLET_USB_HANWANG config TABLET_USB_KBTAB tristate "KB Gear JamStudio tablet support (USB)" - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help Say Y here if you want to use the USB version of the KB Gear JamStudio tablet. Make sure to say Y to "Mouse support" @@ -75,9 +71,8 @@ config TABLET_USB_KBTAB config TABLET_USB_WACOM tristate "Wacom Intuos/Graphire tablet support (USB)" - depends on USB_ARCH_HAS_HCD + depends on USB select POWER_SUPPLY - select USB select NEW_LEDS select LEDS_CLASS help diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 3b9758b..a889c52 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -689,8 +689,7 @@ config TOUCHSCREEN_WM97XX_ZYLONITE config TOUCHSCREEN_USB_COMPOSITE tristate "USB Touchscreen Driver" - depends on USB_ARCH_HAS_HCD - select USB + depends on USB help USB Touchscreen driver for: - eGalax Touchkit USB (also includes eTurboTouch CT-410/510/700) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 5a79c33..ee59842 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -126,9 +126,8 @@ if RC_DEVICES config RC_ATI_REMOTE tristate "ATI / X10 based USB RF remote controls" - depends on USB_ARCH_HAS_HCD + depends on USB depends on RC_CORE - select USB help Say Y here if you want to use an X10 based USB remote control. These are RF remotes with USB receivers. @@ -159,9 +158,8 @@ config IR_ENE config IR_IMON tristate "SoundGraph iMON Receiver and Display" - depends on USB_ARCH_HAS_HCD + depends on USB depends on RC_CORE - select USB ---help--- Say Y here if you want to use a SoundGraph iMON (aka Antec Veris) IR Receiver and/or LCD/VFD/VGA display. @@ -171,9 +169,8 @@ config IR_IMON config IR_MCEUSB tristate "Windows Media Center Ed. eHome Infrared Transceiver" - depends on USB_ARCH_HAS_HCD + depends on USB depends on RC_CORE - select USB ---help--- Say Y here if you want to use a Windows Media Center Edition eHome Infrared Transceiver. @@ -221,9 +218,8 @@ config IR_NUVOTON config IR_REDRAT3 tristate "RedRat3 IR Transceiver" - depends on USB_ARCH_HAS_HCD + depends on USB depends on RC_CORE - select USB ---help--- Say Y here if you want to use a RedRat3 Infrared Transceiver. @@ -232,9 +228,8 @@ config IR_REDRAT3 config IR_STREAMZAP tristate "Streamzap PC Remote IR Receiver" - depends on USB_ARCH_HAS_HCD + depends on USB depends on RC_CORE - select USB ---help--- Say Y here if you want to use a Streamzap PC Remote Infrared Receiver. @@ -261,9 +256,8 @@ config IR_WINBOND_CIR config IR_IGUANA tristate "IguanaWorks USB IR Transceiver" - depends on USB_ARCH_HAS_HCD + depends on USB depends on RC_CORE - select USB ---help--- Say Y here if you want to use the IguanaWorks USB IR Transceiver. Both infrared receive and send are supported. If you want to @@ -277,9 +271,8 @@ config IR_IGUANA config IR_TTUSBIR tristate "TechnoTrend USB IR Receiver" - depends on USB_ARCH_HAS_HCD + depends on USB depends on RC_CORE - select USB select NEW_LEDS select LEDS_CLASS ---help--- diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 73f62ca..c530ad9 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -33,7 +33,7 @@ config USB_ARCH_HAS_HCD # ARM SA1111 chips have a non-PCI based "OHCI-compatible" USB host interface. config USB tristate "Support for Host-side USB" - depends on USB_ARCH_HAS_HCD + depends on USB_ARCH_HAS_HCD && HAS_DMA select NLS # for UTF-8 strings ---help--- Universal Serial Bus (USB) is a specification for a serial bus
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 <geert@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(-)