netdev - 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: <20211005223014.3891f041@thinkpad>
Date:   Tue, 5 Oct 2021 22:30:14 +0200
From:   Marek Behún <kabel@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Rob Herring <robh+dt@...nel.org>, Pavel Machek <pavel@....cz>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        "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 Mon, 4 Oct 2021 19:28:19 +0200
Andrew Lunn <andrew@...n.ch> wrote:

> > > There are two different ways this can be implemented. There can be two
> > > independent LEDs within the same package. So you can generate three
> > > colours. Or there can be two cross connected LEDs within the
> > > package. Apply +ve you get one colour, apply -ve you get a different
> > > colour. Since you cannot apply both -ve and +ve at the same time, you
> > > cannot get both colours at once.
> > > 
> > > If you have two independent LEDs, I would define two LEDs in DT.  
> > 
> > No, we have multicolor LED API which is meant for exactly this
> > situation: a multicolor LED.
> > (I am talking about something like the KJ2518D-262 from
> >  http://www.rego.com.tw/product_detail.php?prdt_id=258
> >  which has Green/Orange on left and Yellow on right side.
> >  The left Green/Orange LED has 3 pins, and so it can mix the colors into
> >  yellow.)  
> 
> But here you are talking about the LED, not the controller in the
> PHY. The controller might control it as two independent LEDs. It has
> no idea it can get a third colour by enabling two LEDs at the same
> time. Or maybe the controller does know it can combine colours.
> 
> So you need to know about both the controller and the LED. And the
> same controller can be used either way. Plus you need to think about
> the non DT case, when you have no idea about the LED connected to the
> controller.
> 
> > I think the best solution here would be a subclass "enumcolor" (or
> > different name), where you can choose between several pre-defined colors.
> > In sysfs you could then do
> >   echo 1 >brightness
> >   echo green >color
> >   echo yellow >color  
> 
> I'm not sure it is as simple as that. In the general case, you have no
> idea what the colours actually are. You only know the colours if you
> have DT and DT lists the colours. And you only know if LEDs are
> combined if you have DT. You need a basic sysfs API based on knowing
> the PHY can control X LEDs. You can then extend that API if you have
> additional information via DT, like colour and if LEDs are combined,
> that only LEDs numbered 2 and 3 are used, etc.
> 
> 	   Andrew

I really don't think we should be registering any LEDs in the PHY driver
if the driver does not know whether there are LEDs connected to the PHY.

If this information is not available (via device-tree or some other
method, for example USB vendor/device table), then we can't register a
LED and let user control it.

What if the pin is used for something different on a board?

Marek