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

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

Date:   Tue, 10 Aug 2021 22:46:01 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Marek Behún <kabel@...nel.org>,
        Michael Walle <michael@...le.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, sasha.neftin@...el.com,
        vinicius.gomes@...el.com, vitaly.lifshits@...el.com
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs

On 10.08.2021 19:29, Pavel Machek wrote:
> Hi!
> 
>>> Yes, this still persists. But we really do not want to start
>>> introducing namespaces to the LED subsystem.
>>
>> 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
> 
> So "r8159-0300:green:activity" would be closer to the naming we want,

The LED ports in the network chip are multi-function. You can select activity
or link or both. Supposedly renaming the device on function switch is not an
attractive option. Any proposal on how to handle this?

Also the NIC has no clue about the color of the LEDs in the RJ45 port.
Realtek network chips driven by r8169 can be found on basically every
consumer mainboard. Determining LED color would need hundreds of DMI
match entries and would be a maintenance nightmare.
So color would need to be empty?

> but lets not do that, we really want this to be similar to what others
> are doing, and that probably means "ethphy3:green:activity" AFAICT.
> 
A challenge here would be unique numbering if there are multiple
network interfaces with LED support (especially if the interfaces
use different drivers). So the numbering service would have to be
in LED subsystem core or network subsystem core.

> Best regards,
> 								Pavel
>