WSL2-Linux-Kernel/drivers/usb/core/Kconfig

119 строки
4.3 KiB
Plaintext
Исходник Обычный вид История

# SPDX-License-Identifier: GPL-2.0
#
# USB Core configuration
#
config USB_ANNOUNCE_NEW_DEVICES
bool "USB announce new devices"
help
Say Y here if you want the USB core to always announce the
idVendor, idProduct, Manufacturer, Product, and SerialNumber
strings for every new USB device to the syslog. This option is
usually used by distro vendors to help with debugging and to
let users know what specific device was added to the machine
in what location.
If you do not want this kind of information sent to the system
log, or have any doubts about this, say N here.
comment "Miscellaneous USB options"
config USB_DEFAULT_PERSIST
bool "Enable USB persist by default"
default y
help
Say N here if you don't want USB power session persistence
enabled by default. If you say N it will make suspended USB
devices that lose power get reenumerated as if they had been
unplugged, causing any mounted filesystems to be lost. The
persist feature can still be enabled for individual devices
through the power/persist sysfs node. See
Documentation/driver-api/usb/persist.rst for more info.
If you have any questions about this, say Y here, only say N
if you know exactly what you are doing.
config USB_FEW_INIT_RETRIES
bool "Limit USB device initialization to only a few retries"
help
When a new USB device is detected, the kernel tries very hard
to initialize and enumerate it, with lots of nested retry loops.
This almost always works, but when it fails it can take a long time.
This option tells the kernel to make only a few retry attempts,
so that the total time required for a failed initialization is
no more than 30 seconds (as required by the USB OTG spec).
Say N here unless you require new-device enumeration failure to
occur within 30 seconds (as might be needed in an embedded
application).
config USB_DYNAMIC_MINORS
bool "Dynamic USB minor allocation"
help
If you say Y here, the USB subsystem will use dynamic minor
allocation for any device that uses the USB major number.
This means that you can have more than 16 of a single type
of device (like USB printers).
If you are unsure about this, say N here.
config USB_OTG
bool "OTG support"
depends on PM
help
The most notable feature of USB OTG is support for a
"Dual-Role" device, which can act as either a device
or a host. The initial role is decided by the type of
plug inserted and can be changed later when two dual
role devices talk to each other.
Select this only if your board has Mini-AB/Micro-AB
connector.
config USB_OTG_PRODUCTLIST
bool "Rely on OTG and EH Targeted Peripherals List"
depends on USB
help
If you say Y here, the "otg_productlist.h" file will be used as a
product list, so USB peripherals not listed there will be
rejected during enumeration. This behavior is required by the
USB OTG and EH specification for all devices not on your product's
"Targeted Peripherals List". "Embedded Hosts" are likewise
allowed to support only a limited number of peripherals.
config USB_OTG_DISABLE_EXTERNAL_HUB
bool "Disable external hubs"
depends on USB_OTG || EXPERT
help
If you say Y here, then Linux will refuse to enumerate
external hubs. OTG hosts are allowed to reduce hardware
and software costs by not supporting external hubs. So
are "Embedded Hosts" that don't offer OTG support.
config USB_OTG_FSM
tristate "USB 2.0 OTG FSM implementation"
depends on USB && USB_OTG
select USB_PHY
help
Implements OTG Finite State Machine as specified in On-The-Go
and Embedded Host Supplement to the USB Revision 2.0 Specification.
usb: core: Introduce a USB port LED trigger 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 <rafal@milecki.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-16 17:13:48 +03:00
config USB_LEDS_TRIGGER_USBPORT
tristate "USB port LED trigger"
depends on USB && LEDS_TRIGGERS
help
This driver allows LEDs to be controlled by USB events. Enabling this
trigger allows specifying list of USB ports that should turn on LED
when some USB device gets connected.
config USB_AUTOSUSPEND_DELAY
int "Default autosuspend delay"
depends on USB
default 2
help
The default autosuspend delay in seconds. Can be overridden
with the usbcore.autosuspend command line or module parameter.
The default value Linux has always had is 2 seconds. Change
this value if you want a different delay and cannot modify
the command line or module parameter.