mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-15 06:46:41 +07:00
0f247626cb
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>
42 lines
1.3 KiB
Plaintext
42 lines
1.3 KiB
Plaintext
USB port LED trigger
|
|
====================
|
|
|
|
This LED trigger can be used for signalling to the user a presence of USB device
|
|
in a given port. It simply turns on LED when device appears and turns it off
|
|
when it disappears.
|
|
|
|
It requires selecting USB ports that should be observed. All available ones are
|
|
listed as separated entries in a "ports" subdirectory. Selecting is handled by
|
|
echoing "1" to a chosen port.
|
|
|
|
Please note that this trigger allows selecting multiple USB ports for a single
|
|
LED. This can be useful in two cases:
|
|
|
|
1) Device with single USB LED and few physical ports
|
|
|
|
In such a case LED will be turned on as long as there is at least one connected
|
|
USB device.
|
|
|
|
2) Device with a physical port handled by few controllers
|
|
|
|
Some devices may have one controller per PHY standard. E.g. USB 3.0 physical
|
|
port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there is
|
|
only one LED user will most likely want to assign ports from all 3 hubs.
|
|
|
|
|
|
This trigger can be activated from user space on led class devices as shown
|
|
below:
|
|
|
|
echo usbport > trigger
|
|
|
|
This adds sysfs attributes to the LED that are documented in:
|
|
Documentation/ABI/testing/sysfs-class-led-trigger-usbport
|
|
|
|
Example use-case:
|
|
|
|
echo usbport > trigger
|
|
echo 1 > ports/usb1-port1
|
|
echo 1 > ports/usb2-port1
|
|
cat ports/usb1-port1
|
|
echo 0 > ports/usb1-port1
|