On 1.03.2023 14:43, Rob Herring wrote:
On Wed, Mar 1, 2023 at 1:27 AM Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
On 1.03.2023 01:02, Rob Herring wrote:
On Tue, Feb 28, 2023 at 03:49:33PM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki <rafal@xxxxxxxxxx>
It's a trigger used on many home routers that have LEDs to indicate
specific USB port state.
Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx>
---
Documentation/devicetree/bindings/leds/common.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index 15e3f6645682..95b316ee3146 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -99,6 +99,7 @@ properties:
- pattern
- usb-gadget
- usb-host
+ - usbport
Can we stop adding entries which are clearly likely to have multiple
instances. We have a better binding to map the trigger source...
I'm sorry, I really don't understand this.
I'm not sure what do you mean by multuple "usbport" instances.
Could you point me to that better place, please?
Suppose I have a device with 4 USB ports and 4 LEDs for each one. How
would one define the connection of LEDs to USB ports? Extend this to
usbport[0-9]? No.
This is probably something obvious but I really can't figure it out
since yesterday.
"trigger-sources"
Ah, I suppose that "usbport" LED trigger in Linux can be confusing.
So: no matter how many USB ports you have, Linux *doesn't* create one
trigger per USB port. There is only one trigger. It's called exactly
"usbport".
Once you choose "usbport" trigger in Linux, you can choose which ports
should it "monitor". That can be done using procfs (ABI). The default
set of ports to monitor can be specified using "trigger-sources".
For decision details behind this see 0f247626cbbf ("usb: core: Introduce
a USB port LED trigger").
So Linux on home routers needs both:
1. linux,default-trigger (for selecting default trigger)
2. trigger-sources (for providing default set of ports to monitor)
Does it make more sense? Should I improve commit description and resend
it? Or should we still rework it somehow?
