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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <0b1bc2d7-6e62-5adb-5aed-48b99770d80d@gmail.com>
Date:   Tue, 5 Oct 2021 21:58:13 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Marek Behún <kabel@...nel.org>,
        Andrew Lunn <andrew@...n.ch>
Cc:     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

Hi Marek,

On 10/4/21 5:08 PM, Marek Behún wrote:
> On Mon, 4 Oct 2021 16:50:09 +0200
> Andrew Lunn <andrew@...n.ch> wrote:
> 
>>> Hello Andrew,
>>>
>>> I am aware of this, and in fact am working on a proposal for an
>>> extension of netdev LED extension, to support the different link
>>> modes. (And also to support for multi-color LEDs.)
>>>
>>> But I am not entirely sure whether these different link modes should be
>>> also definable via device-tree. Are there devices with ethernet LEDs
>>> dedicated for a specific speed? (i.e. the manufacturer says in the
>>> documentation of the device, or perhaps on the device's case, that this
>>> LED shows 100M/1000M link, and that other LED is shows 10M link?)
>>> If so, that this should be specified in the devicetree, IMO. But are
>>> such devices common?
>>
>> I have a dumb 5 port switch next to me. One port is running at 1G. Its
>> left green LED is on and blinks with traffic. Another port of the
>> switch is running at 100Mbps and its right orange LED is on, blinks
>> for traffic. And there is text on the case saying 10/100 orange, 1G
>> green.
>>
>> I think this is pretty common. You generally do want to know if 10/100
>> is being used, it can indicate problems. Same for a 10G port running
>> at 1G, etc.
> 
> OK then. I will work no a proposal for device tree bindings for this.
> 
>>> And what about multi-color LEDs? There are ethernet ports where one LED
>>> is red-green, and so can generate red, green, and yellow color. Should
>>> device tree also define which color indicates which mode?
>>
>> 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.

Multicolor LED framework is especially useful for the arrangements
where we want to have a possibility of controlling mixed LED color
in a wide range.
In the discussed case it seems that having two separate LED class
devices will be sufficient. Unless the LEDs have 255 or so possible
brightness levels each and they can produce meaningful mixed color
per some device state.

> (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.)
> 
>> Things get tricky for the two dependency LEDs. Does the LED core have
>> support for such LEDs?
> 
> Unfortunately not yet. The multicolor API supports LEDs where the
> sub-leds are independent.

What do you mean by dependency here? You can write LED multicolor class
driver that will aggregate whatever LEDs you want, provided that it will
know how to control them. However, the target use case was RGB LED
controllers.

>> This is where we need to strike a balance between too simple and too
>> complex. Implement most of the common features, but don't support
>> exotic stuff, like two dependency LEDs?
> 
> 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
> 
> There already are other people who need to register such LEDs.
> 
> Marek
> 

-- 
Best regards,
Jacek Anaszewski