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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx> 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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux