linux-kernel - Re: 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20211005234342.7334061b@thinkpad>
Date:   Tue, 5 Oct 2021 23:43:42 +0200
From:   Marek Behún <kabel@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Rob Herring <robh+dt@...nel.org>, Pavel Machek <pavel@....cz>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: lets settle the LED `function` property regarding the netdev
 trigger

On Tue, 5 Oct 2021 23:01:18 +0200
Andrew Lunn <andrew@...n.ch> wrote:

> > In the discussed case (ethernet PHY LEDs) - it is sometimes possible to
> > have multiple brightness levels per color channel. For example some
> > Marvell PHYs allow to set 8 levels of brightness for Dual Mode LEDs.
> > Dual Mode is what Marvell calls when the PHY allows to pair two
> > LED pins to control one dual-color LED (green-red, for example) into
> > one.
> > 
> > Moreover for this Dual Mode case they also allow for HW control of
> > this dual LED, which, when enabled, does something like this, in HW:
> >   1g link	green
> >   100m link	yellow
> >   10m link	red
> >   no link	off
> > 
> > Note that actual colors depend on the LEDs themselves. The PHY
> > documentation does not talk about the color, only about which pin is
> > on/off. The thing is that if we want to somehow set this mode for the
> > LED, it should be represented as one LED class device.
> > 
> > I want to extend the netdev trigger to support such configuration,
> > so that when you have multicolor LED, you will be able to say which
> > color should be set for which link mode.  
> 
> This is getting into the exotic level i don't think we need to
> support. How many PHYs have you seen that support something like this?

This isn't about whether there are PHYs which support this in HW.
The extension to netdev trigger will be able to do this in SW.

For example the Turris Omnia has 12 RGB LEDs on the front panel, of
which 6 are dedicated to ethernet ports (and there are no LEDs on
ethernet ports themselves). It would make sense to be able to have
netdev trigger (or it's extension) show link mode by color (for example
green on 1g, yellow on 100g, orange on 10g).

Anyway when you have a green-yellow LED on an ethernet port wired in
such a way than it can only be off, green or yellow, but not both green
and yellow, I don't think we should register these as 2 LED class
devices.

> 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 :)

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";
- having separate functions for different link modes
    function = "link1000", "link100";
  or should this insted be in another property
    function = "link";
    link-modes = <1000 100>;
  ?

Marek