kernel/linux.git/drivers/usb/core/Kconfig, branch v6.18.21

usb: core: Kconfig: Improve USB authorization mode help

2024-02-17T15:38:35+00:00

Update the default USB device authorization mode help text so that the meaning of the option and it's available values are described more accurately. Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/linux-usb/CAMuHMdUy793gzDVR0jfNnx5TUdJ_2MKH5NPGSgHkytAhArtqmw@mail.gmail.com/ Signed-off-by: Niko Mauno Link: https://lore.kernel.org/r/20240213124518.20231-1-niko.mauno@vaisala.com Signed-off-by: Greg Kroah-Hartman

usb: core: Make default authorization mode configurable

2024-01-28T01:35:49+00:00

Make the default USB device authorization mode configurable at build time. This is useful for systems that require a mode that is stricter than the standard setting, as it avoids relying on the kernel command line being properly set. Signed-off-by: Niko Mauno Link: https://lore.kernel.org/r/20240105114956.30714-2-niko.mauno@vaisala.com Signed-off-by: Greg Kroah-Hartman

USB: hub: Add Kconfig option to reduce number of port initialization retries

2020-10-02T09:29:02+00:00

Description based on one by Yasushi Asano: According to 6.7.22 A-UUT “Device No Response” for connection timeout of USB OTG and EH automated compliance plan v1.2, enumeration failure has to be detected within 30 seconds. However, the old and new enumeration schemes each make a total of 12 attempts, and each attempt can take 5 seconds to time out, so the PET test fails. This patch adds a new Kconfig option (CONFIG_USB_FEW_INIT_RETRIES); when the option is set all the initialization retry loops except the outermost are reduced to a single iteration. This reduces the total number of attempts to four, allowing Linux hosts to pass the PET test. The new option is disabled by default to preserve the existing behavior. The reduced number of retries may fail to initialize a few devices that currently do work, but for the most part there should be no change. And in cases where the initialization does fail, it will fail much more quickly. Reported-and-tested-by: yasushi asano Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20200928152217.GB134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

USB: OTG: rename product list of devices

2020-06-19T06:58:55+00:00

Rename the list of specific devices that an OTG device could support to make it more obvious as to what this list is for and what it is doing. Also rename the configuration option to make it more obvious as well. Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: "Diego Elio Pettenò" Cc: "Martin K. Petersen" Cc: Jens Axboe Cc: Jiaxun Yang Cc: Krzysztof Kozlowski Cc: "Philippe Mathieu-Daudé" Cc: Alan Stern Cc: Eugeniu Rosca Cc: Qi Zhou Cc: Andrey Konovalov Cc: Hardik Gajjar Cc: Harry Pan Cc: David Heinzelmann Cc: Nishad Kamdar Link: https://lore.kernel.org/r/20200618094300.1887727-9-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

USB: rename USB OTG hub configuration option

2020-06-19T06:58:42+00:00

The USB OTG code has the ability to disable external hubs, but the configuration option for it is oddly named. Rename it to be more obvious as to what it does. Cc: Thomas Bogendoerfer Cc: Bin Liu Cc: Paul Cercueil Cc: Alan Stern Cc: Eugeniu Rosca Cc: Kai-Heng Feng Cc: David Heinzelmann Cc: "Lee, Chiasheng" Cc: Keiya Nobuta Cc: Hardik Gajjar Link: https://lore.kernel.org/r/20200618094300.1887727-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

usb: remove redundant 'default n' from Kconfig-s

2019-05-21T08:06:22+00:00

'default n' is the default value for any bool or tristate Kconfig setting so there is no need to write it explicitly. Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO is not set' for visible symbols") the Kconfig behavior is the same regardless of 'default n' being present or not: ... One side effect of (and the main motivation for) this change is making the following two definitions behave exactly the same: config FOO bool config FOO bool default n With this change, neither of these will generate a '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied). That might make it clearer to people that a bare 'default n' is redundant. ... Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

usb: core: make default autosuspend delay configurable

2019-03-01T19:53:41+00:00

Make the default autosuspend delay configurable at build time. This is useful for systems that require a non-standard value as it avoids relying on the command line being properly set. Signed-off-by: Mans Rullgard Signed-off-by: Greg Kroah-Hartman

USB: add missing SPDX lines to Kconfig and Makefiles

2019-01-22T08:08:17+00:00

There are a few remaining drivers/usb/ files that do not have SPDX identifiers in them, all of these are either Kconfig or Makefiles. Add the correct GPL-2.0 identifier to them to make scanning tools happy. Signed-off-by: Greg Kroah-Hartman

docs-rst: fix usb cross-references

2017-04-11T20:41:29+00:00

As some USB documentation files got moved, adjust their cross-references to their new place. Signed-off-by: Mauro Carvalho Chehab Acked-by: Greg Kroah-Hartman Signed-off-by: Jonathan Corbet

usb: core: Introduce a USB port LED trigger

2016-09-27T10:20:17+00:00

This commit adds a new trigger responsible for turning on LED when USB device gets connected to the selected USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1). There was a long discussion on design of this driver. Its current state is a result of picking them most adjustable solution as others couldn't handle all cases. 1) It wasn't possible for the driver to register separated trigger for each USB port. Some physical USB ports are handled by more than one controller and so by more than one USB port. E.g. USB 2.0 physical port may be handled by OHCI's port and EHCI's port. It's also not possible to assign more than 1 trigger to a single LED and implementing such feature would be tricky due to syncing triggers and sysfs conflicts with old triggers. 2) Another idea was to register trigger per USB hub. This wouldn't allow handling devices with multiple USB LEDs and controllers (hubs) controlling more than 1 physical port. It's common for hubs to have few ports and each may have its own LED. This final trigger is highly flexible. It allows selecting any USB ports for any LED. It was also modified (comparing to the initial version) to allow choosing ports rather than having user /guess/ proper names. It was successfully tested on SmartRG SR400ac which has 3 USB LEDs, 2 physical ports and 3 controllers. It was noted USB subsystem already has usb-gadget and usb-host triggers but they are pretty trivial ones. They indicate activity only and can't have ports specified. In future it may be good idea to consider adding activity support to usbport as well. This should allow switching to this more generic driver and maybe marking old ones as obsolete. This can be implemented with another sysfs file for setting mode. The default mode wouldn't change so there won't be ABI breakage and so such feature can be safely implemented later. There was also an idea of supporting other devices (PCI, SDIO, etc.) but as this driver already contains some USB specific code (and will get more) these should be probably separated drivers (triggers). Signed-off-by: Rafał Miłecki Signed-off-by: Greg Kroah-Hartman