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

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

 





On 7/21/2021 1: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.

The complication is that both these schemes are used already in
upstream kernel, and we have to maintain backwards compatibility of
sysfs ABI, so we can't change that.

I have been thinking for some time that maybe we should poll Linux
kernel developers about these two schemes, so that a consensus is
reached. Afterwards we can deprecate the other scheme and add a Kconfig
option (default n for backwards compatibility) to use the new scheme.

What do you think?

FWIW, dev_name() should be the "devicename" from what you described above. This is foundational property for all devices that Linux registers that is used for logging, name spacing within /sys/, uniqe, ABI stable, etc. Anything different would be virtually impossible to maintain and would lead to ABI breakage down the road, guaranteed.

Yes it can be long (especially with PCI devices), and unfriendly, but hey, udev to the rescue then, rename based on user preferences.
--
Florian



[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