lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Oct 2021 01:06:06 +0200
From:   Marek BehĂșn <>
To:     Andrew Lunn <>
Cc:     Jacek Anaszewski <>,
        Rob Herring <>, Pavel Machek <>,
        "" <>,,,
Subject: Re: lets settle the LED `function` property regarding the netdev

On Wed, 6 Oct 2021 00:06:58 +0200
Andrew Lunn <> wrote:

> > > 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
> > - having separate functions for different link modes
> >     function = "link1000", "link100";  
> I would suggest this, so you can use 
> function = "link1000", "link100", "activity"

The problem here is that LED core uses function to compose LED name:
Should we use the first function? Then this LED will be named:
but it also indicates link100...

> 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?

This is again sidetrack from the original discussion, which was only
meant to discuss DT, but okay :)

> 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

No, my current ideas about the netdev trigger extension are as follows
(not yet complete):

$ cd /sys/.../<LED>
$ echo netdev >trigger	# To enable netdev trigger
$ echo eth0 >device_name
$ echo 1 >ext		# To enable extended netdev trigger.
			# This will create directory modes if there is
			# a PHY attached to the interface  
$ ls modes/		
1000baseT_Full 100BaseT_Full 100BaseT_Half 10BaseT_Full 10BaseT_Half

$ cd modes/1000baseT_Full
$ ls
brightness link rx tx interval

So basically if you enable the extended netdev trigger, you will get
all the standard netdev settings for each PHY mode. (With a little
change to support blinking on link.)

With this you can set the LED:
  ON when linked and speed=1000m or 100m, blink on activity
  blink with 50ms interval when speed=1000m
  blink with 100ms interval when speed=100m
  blink with 200ms interval when speed=10m

(Note that these don't need to be supported by PHY. We are talking
 about SW control. If the PHY supports some of these in HW, then the
 trigger can be offloaded.)


Powered by blists - more mailing lists