linux-kernel - lets settle the LED `function` property regarding the netdev trigger

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Oct 2021 14:36:01 +0200
From:   Marek Behún <kabel@...nel.org>
To:     Pavel Machek <pavel@....cz>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Rob Herring <robh+dt@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: lets settle the LED `function` property regarding the netdev
 trigger

Hello Pavel, Jacek, Rob and others,

I'd like to settle DT binding for the LED function property regarding
the netdev LED trigger.

Currently we have, in include/dt-bindings/leds/common.h, the following
functions defined that could be interpreted as request to enable netdev
trigger on given LEDs:
  activity
  lan
  rx tx
  wan
  wlan

The "activity" function was originally meant to imply the CPU
activity trigger, while "rx" and "tx" are AFAIK meant as UART indicators
(tty LED trigger), see
https://lore.kernel.org/linux-leds/20190609190803.14815-27-jacek.anaszewski@gmail.com/

The netdev trigger supports different settings:
- indicate link
- blink on rx, blink on tx, blink on both

The current scheme does not allow for implying these.

I therefore propose that when a LED has a network device handle in the
trigger-sources property, the "rx", "tx" and "activity" functions
should also imply netdev trigger (with the corresponding setting).
A "link" function should be added, also implying netdev trigger.

What about if a LED is meant by the device vendor to indicate both link
(on) and activity (blink)?
The function property is currently a string. This could be changed to
array of strings, and then we can have
  function = "link", "activity";
Since the function property is also used for composing LED classdev
names, I think only the first member should be used for that.

This would allow for ethernet LEDs with names
  ethphy-0:green:link
  ethphy-0:yellow:activity
to be controlled by netdev trigger in a specific setting without the
need to set the trigger in /sys/class/leds.

Opinions?

Marek