Thread (17 messages) flat view 17 messages, 3 authors, 2021-10-07

Re: lets settle the LED `function` property regarding the netdev trigger

From: Andrew Lunn <andrew@lunn.ch>
Date: 2021-10-05 22:07:06
Also in: linux-devicetree, linux-leds, lkml

quoted
I suggest we start with simple independent LEDs. That gives enough to
support the majority of use cases people actually need. And is enough
to unblock people who i keep NACKing patches and tell them to wait for
this work to get merged.
Of course, and I plan to do so. Those netdev trigger extensions and
multi-color function definitions are for later :)
Great.
 
We got side tracked in this discussion, sorry about that.

In this thread I just wanted to settle the LED function property for
LEDs indicating network ports.

So would you, Andrew, agree with:
- extending function property to be array of strings instead of only
  one string, so that we can do
    function = "link", "activity";
I agree with having a list, and we use the combination. If the
combination is not possible by the hardware, then -EINVAL, or
-EOPNOTSUPP.
- having separate functions for different link modes
    function = "link1000", "link100";
I would suggest this, so you can use 

function = "link1000", "link100", "activity"

What could be interesting is how you do this in sysfs?  How do you
enumerate what the hardware can do? How do you select what you want?

Do you need to do

echo "link1000 link100 activity" > /sys/class/net/eth0/phy/led/function

And we can have something like

cat /sys/class/net/eth0/phy/led/function
activity
link10 activity
link100 activity
link1000 activity
[link100 link1000 activity]
link10
link100
link1000

each line being a combination the hardware supports, and the line in
[] is the currently select function.

   Andrew



Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help