![Rafał Miłecki](/assets/img/avatar_default.png)
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>
93 lines
3.2 KiB
Plaintext
93 lines
3.2 KiB
Plaintext
#
|
|
# 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/usb/persist.txt 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_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
|
|
default n
|
|
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_WHITELIST
|
|
bool "Rely on OTG and EH Targeted Peripherals List"
|
|
depends on USB
|
|
help
|
|
If you say Y here, the "otg_whitelist.h" file will be used as a
|
|
product whitelist, 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_BLACKLIST_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.
|
|
|
|
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.
|