netdev - Re: [PATCH net-next 5/5] igc: Export LEDs

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]

Date:   Wed, 28 Jul 2021 22:43:30 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Marek Behún <kabel@...nel.org>,
        Michael Walle <michael@...le.cc>
Cc:     andrew@...n.ch, anthony.l.nguyen@...el.com, bigeasy@...utronix.de,
        davem@...emloft.net, dvorax.fuxbrumer@...ux.intel.com,
        f.fainelli@...il.com, jacek.anaszewski@...il.com, kuba@...nel.org,
        kurt@...utronix.de, linux-leds@...r.kernel.org,
        netdev@...r.kernel.org, pavel@....cz, sasha.neftin@...el.com,
        vinicius.gomes@...el.com, vitaly.lifshits@...el.com
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs

On 27.07.2021 18:32, Marek Behún wrote:
> Hi,
> 
> On Tue, 27 Jul 2021 17:53:58 +0200
> Michael Walle <michael@...le.cc> wrote:
> 
>>> If we used the devicename as you are suggesting, then for the two LEDs
>>> the devicename part would be the same:
>>>   ledA -> macA -> ethernet0
>>>   ledB -> phyB -> ethernet0
>>> although they are clearly on different MACs.  
>>
>> Why is that the case? Why can't both the MAC and the PHY request a 
>> unique name from the same namespace?
> 
> So all the network related devices should request a unique network
> relate device ID? Should also wireless PHY devices do this? WWAN modems?
> And all these should have the same template for devicename part withing
> /sys/class/leds? What should be the template for the devicename, if
> wireless PHYs and WWAN modems could also be part of this? It cannot be
> "ethernet" anymore.
> 
> It seems a better idea to me to just some nice identifier for the LED
> controller.
> 
>> As Andrew pointed out, the names in
>> /sys/class/leds don't really matter. Ok, it will still depend on the
>> probe order which might not be the case if you split it between ethmac
>> and ethphy.
> 
> Yes, the LED name does not matter. But the LED subsystem requires names
> in a specific format, this is already decided and documented, we are
> not going to be changing this. The only reasonable thing we can do now
> is to choose a sane devicename.
> 
>> Sorry, if I may ask stupid questions here. I don't want to cause much
>> trouble, here. I was just wondering why we have to make up two different
>> (totally unrelated names to the network interface names) instead of just
>> one (again totally unrelated to the interface name and index).
> 
> It seems more logical to me from kernel's point of view.
> 
>> But I was actually referring to your "you see the leds in /sys/ of all
>> the network adapters". That problem still persists, right?
> 
> Yes, this still persists. But we really do not want to start
> introducing namespaces to the LED subsystem.
> 
> Marek
> 

Did we come to any conclusion?

My preliminary r8169 implementation now creates the following LED names:

lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led0-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led0-0300
lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led1-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led1-0300
lrwxrwxrwx 1 root root 0 Jul 26 22:50 r8169-led2-0300 -> ../../devices/pci0000:00/0000:00:1d.0/0000:03:00.0/net/enp3s0/r8169-led2-0300

I understood that LEDs should at least be renamed to r8169-0300::link-0
to link-2 Is this correct? Or do we have to wait with any network LED support
for a name discussion outcome?

For the different LED modes I defined private hw triggers (using trigger_type
to make the triggers usable with r8169 LEDs only). The trigger attribute now
looks like this:

[none] link_10_100 link_1000 link_10_100_1000 link_ACT link_10_100_ACT link_1000_ACT link_10_100_1000_ACT

Nice, or? Issue is just that these trigger names really should be made a
standard for all network LEDs. I don't care about the exact naming, important
is just that trigger names are the same, no matter whether it's about a r8169-
or igc- or whatever network chip controlled LEDs.

And I don't have a good solution for initialization yet. LED mode is whatever
BIOS sets, but initial trigger value is "none". I would have to read the
initial LED control register values, iterate over the triggers to find the
matching one, and call led_trigger_set() to properly set this trigger as
current trigger. Most likely this would need some LED core extensions:
- enable iterating over all triggers with a particular trigger_type
- enable triggers to have private data
Quite some hassle for a small functionality.