Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On Thu 2016-09-15 15:33:19, Rafał Miłecki wrote: > On 15 September 2016 at 14:56, Pavel Machek wrote: > > On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: > >> On 9 September 2016 at 13:05, Greg KH wrote: > >> > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: > >> >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: > >> >> > From: Rafał Miłecki > >> >> > > >> >> > 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 (compared 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. > >> >> > > >> >> > Another planned feature is support for LED reacting to the USB > >> >> > activity. > >> >> > 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 such > >> >> > feature can be safely implemented later. > >> >> > > >> >> > >> >> It has such driver at: drivers/usb/common/led.c > >> > > >> > Ugh, I thought I had seen something like this before... > >> > > >> > Rafał, can you just use this in-kernel code instead? > >> > >> I really don't think I can because of all the reasons I carefully > >> listed in the commit message. > >> > >> Have you took a look at that simple driver? It does nothing I need. > >> Its design doesn't allow implementing features I clearly listed in the > >> commit message. > > > > In any case, the new driver should probably go near the old one, at > > the very least. > > I can do that. Anyone objects? I did not have time to study your patches in detail. IIRC there was something like "directory full of usb IDs". I'm not sure that's a way to go. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On 09/15/2016 03:33 PM, Rafał Miłecki wrote: On 15 September 2016 at 14:56, Pavel Machek wrote: On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: On 9 September 2016 at 13:05, Greg KH wrote: On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: From: Rafał Miłecki 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 (compared 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. Another planned feature is support for LED reacting to the USB activity. 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 such feature can be safely implemented later. It has such driver at: drivers/usb/common/led.c Ugh, I thought I had seen something like this before... Rafał, can you just use this in-kernel code instead? I really don't think I can because of all the reasons I carefully listed in the commit message. Have you took a look at that simple driver? It does nothing I need. Its design doesn't allow implementing features I clearly listed in the commit message. In any case, the new driver should probably go near the old one, at the very least. I can do that. Anyone objects? It's OK with me. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On 15 September 2016 at 14:56, Pavel Machek wrote: > On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: >> On 9 September 2016 at 13:05, Greg KH wrote: >> > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: >> >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: >> >> > From: Rafał Miłecki >> >> > >> >> > 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 (compared 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. >> >> > >> >> > Another planned feature is support for LED reacting to the USB activity. >> >> > 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 such >> >> > feature can be safely implemented later. >> >> > >> >> >> >> It has such driver at: drivers/usb/common/led.c >> > >> > Ugh, I thought I had seen something like this before... >> > >> > Rafał, can you just use this in-kernel code instead? >> >> I really don't think I can because of all the reasons I carefully >> listed in the commit message. >> >> Have you took a look at that simple driver? It does nothing I need. >> Its design doesn't allow implementing features I clearly listed in the >> commit message. > > In any case, the new driver should probably go near the old one, at > the very least. I can do that. Anyone objects? -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: > On 9 September 2016 at 13:05, Greg KH wrote: > > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: > >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: > >> > From: Rafał Miłecki > >> > > >> > 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 (compared 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. > >> > > >> > Another planned feature is support for LED reacting to the USB activity. > >> > 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 such > >> > feature can be safely implemented later. > >> > > >> > >> It has such driver at: drivers/usb/common/led.c > > > > Ugh, I thought I had seen something like this before... > > > > Rafał, can you just use this in-kernel code instead? > > I really don't think I can because of all the reasons I carefully > listed in the commit message. > > Have you took a look at that simple driver? It does nothing I need. > Its design doesn't allow implementing features I clearly listed in the > commit message. In any case, the new driver should probably go near the old one, at the very least. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On 9 September 2016 at 13:05, Greg KH wrote: > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: >> > From: Rafał Miłecki >> > >> > 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 (compared 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. >> > >> > Another planned feature is support for LED reacting to the USB activity. >> > 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 such >> > feature can be safely implemented later. >> > >> >> It has such driver at: drivers/usb/common/led.c > > Ugh, I thought I had seen something like this before... > > Rafał, can you just use this in-kernel code instead? I really don't think I can because of all the reasons I carefully listed in the commit message. Have you took a look at that simple driver? It does nothing I need. Its design doesn't allow implementing features I clearly listed in the commit message. -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: > On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > 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 (compared 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. > > > > Another planned feature is support for LED reacting to the USB activity. > > 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 such > > feature can be safely implemented later. > > > > It has such driver at: drivers/usb/common/led.c Ugh, I thought I had seen something like this before... Rafał, can you just use this in-kernel code instead? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On 9 September 2016 at 11:34, Peter Chen wrote: > On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: >> From: Rafał Miłecki >> >> 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 (compared 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. >> >> Another planned feature is support for LED reacting to the USB activity. >> 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 such >> feature can be safely implemented later. >> > > It has such driver at: drivers/usb/common/led.c Oh, great, I had no idea about that. So if it comes to adding activity support, we'll have to well discuss that. We may e.g. not implement that or move existing feature into more generic usbport trigger or partially duplicate this feature. Anyway, I hope this note on "usb-gadget" and "usb-host" triggers won't stop our work on "usbport". This driver implements different thing for now (discovering device in a USB port) and I don't think "usb-gadget" / "usb-host" could be extended to handle such cases. Thanks for a hint though, I'll definitely keep that in mind during further development! -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: > From: Rafał Miłecki > > 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 (compared 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. > > Another planned feature is support for LED reacting to the USB activity. > 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 such > feature can be safely implemented later. > It has such driver at: drivers/usb/common/led.c -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5] leds: trigger: Introduce a USB port trigger
From: Rafał Miłecki 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 (compared 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. Another planned feature is support for LED reacting to the USB activity. 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 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 --- V2: Trying to add DT support, idea postponed as it will take more time to discuss the bindings. V3: Fix typos in commit and Documentation (thanks Jacek!) Use "ports" sysfs file for adding and removing USB ports (thx Jacek) Check if there is USB device connected after adding new USB port Fix memory leak or two V3.5: Fix e-mail address (thanks Matthias) Simplify conditions in usbport_trig_notify (thx Matthias) Make "ports" a subdirectory with file per port, to match one value per file sysfs rule (thanks Greg) As "ports" couldn't be used for adding and removing ports anymore, there are now "new_port" and "remove_port". Having them makes this API also common with e.g. pci and usb buses. V4: Add Documentation/ABI/testing/sysfs-class-led-trigger-usbport and reference it in Documentation/leds/ledtrig-usbport.txt to avoid doc duplication. V5: Update commit message to explain driver design & Documentation Avoid specifying ports manually and dummy files (chmod ) Don't use kobject_create_and_add but a struct attribute_group Fix typo, improve comments, update Date --- .../ABI/testing/sysfs-class-led-trigger-usbport| 11 + Documentation/leds/ledtrig-usbport.txt | 41 +++ drivers/leds/trigger/Kconfig | 8 + drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-usbport.c | 316 + 5 files changed, 377 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-usbport create mode 100644 Documentation/leds/ledtrig-usbport.txt create mode 100644 drivers/leds/trigger/ledtrig-usbport.c diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-usbport b/Documentation/ABI/testing/sysfs-class-led-trigger-usbport new file mode 100644 index 000..a9b7e92 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-usbport @@ -0,0 +1,11 @@ +What: /sys/class/leds//ports/ +Date: September 2016 +KernelVersion: 4.9 +Contact: linux-l...@vger.kernel.org +Description: + Every dir entry represents a single USB port that can be + selected for the USB port trigger. Selecting ports makes trigger + observing them for any connected devices and lighting on LED if + there are any. + Echoing "1" value selects USB port. Echoing "0" unselects it. + Current state can be also read. diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt new file mode 100644 index 000..69f54bf --- /dev/null +++ b/Documentation/leds/ledtrig-usbport.txt @@ -0,0 +1,41 @@ +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