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]

Message-ID: <4d8db4ce-0413-1f41-544d-fe665d3e104c@gmail.com>
Date:   Mon, 26 Jul 2021 19:42:04 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Marek Behún <kabel@...nel.org>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Pavel Machek <pavel@....cz>,
        Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net,
        kuba@...nel.org, Kurt Kanzenbach <kurt@...utronix.de>,
        netdev@...r.kernel.org, sasha.neftin@...el.com,
        vitaly.lifshits@...el.com, vinicius.gomes@...el.com,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Dvora Fuxbrumer <dvorax.fuxbrumer@...ux.intel.com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs

Hi Marek,

On 7/21/21 10:07 PM, Marek Behún wrote:
> On Wed, 21 Jul 2021 21:50:07 +0200
> Andrew Lunn <andrew@...n.ch> wrote:
> 
>>> Hi Heiner,
>>>
>>> in sysfs, all devices registered under LED class will have symlinks in
>>> /sys/class/leds. This is how device classes work in Linux.
>>>
>>> There is a standardized format for LED device names, please look at
>>> Documentation/leds/leds-class.rst.
>>>
>>> Basically the LED name is of the format
>>>    devicename:color:function
>>
>> The interesting part here is, what does devicename mean, in this
>> context?
>>
>> We cannot use the interface name, because it is not unique, and user
>> space can change it whenever it wants. So we probably need to build
>> something around the bus ID, e.g. pci_id. Which is not very friendly
>> :-(
> 
> Unfortunately there isn't consensus about what the devicename should
> mean. There are two "schools of thought":
> 
> 1. device name of the trigger source for the LED, i.e. if the LED
>     blinks on activity on mmc0, the devicename should be mmc0. We have
>     talked about this in the discussions about ethernet PHYs.
>     In the case of the igc driver if the LEDs are controlled by the MAC,
>     I guess some PCI identifier would be OK. Or maybe ethernet-mac
>     identifier, if we have something like that? (Since we can't use
>     interface names due to the possibility of renaming.)
> 
>     Pavel and I are supporters of this scheme.
> 
> 2. device name of the LED controller. For example LEDs controlled by
>     the maxim,max77650-led controller (leds-max77650.c) define device
>     name as "max77650"
> 
>     Jacek supports this scheme.

I believe you must have misinterpreted some my of my statements.
The whole effort behind LED naming unification was getting rid of
hardware device names in favour of Linux provided device names.
See e.g. the excerpt from Documentation/leds/leds-class.rst:

- devicename:
         it should refer to a unique identifier created by the kernel,
         like e.g. phyN for network devices or inputN for input devices, 
rather
         than to the hardware; the information related to the product 
and the bus
         to which given device is hooked is available in sysfs and can be
         retrieved using get_led_device_info.sh script from tools/leds; 
generally
         this section is expected mostly for LEDs that are somehow 
associated with
         other devices.


-- 
Best regards,
Jacek Anaszewski