Re: [RFC PATCH 0/2] leds: Add optional instance identifier for deterministic naming

Jonathan Brophy
2025-12-29T23:59:10Z

>> The problem as I understood not exactly in this. The reporter wants
>> deterministic way of the mapping between HW numbered LEDs and their respective
>> names. It seems it was already mentioned that current code depends on the
>> arbitrary probe ordering. Saying this, I now think that perhaps GPIO led driver
>> should somehow allocate a range of the LEDs and then enumerate them in

> accordance with the DT description?

>function-enumerator DT property enables deterministic enumeration.

>--
>Best regards,
>Jacek Anaszewski

That's not really the the problem I'm trying to solve but it is part of it.
The functions are quite ambiguous at the moment.
Having a string that can define something custom, the fallback _1 _2 identifiers are
high lighting the issue because the lack of options.

I have a virtual led grouping driver that this restriction will highlight the issue even more.
with a status led on a typical oem device that indicate multiple states eg:

- Solid Blue: setting up/ committing settings change.
- Pulse Blue: factory reset/ first boot ready for setup or WPS in progress.
- Fade in-out Blue: system upgrade in progress
- Solid Yellow: starting up.*/
- pulse Yellow: resetting/ rebooting.*/

From sysfs i will end up with the below that really does not explain the use:

led:status:blue
led:status:blue_1
led:ststus:blue_2
led:status:yellow
led:status:yellow_1

The LED subsystem has a semantic ambiguity:
What does LED_FUNCTION_LAN actually mean?
LAN port exists?
LAN cable connected?
LAN link active?
LAN traffic activity?
LAN speed indicator?

Rather than making custom identifiers that are overly specific we could make
them up from stacking qualifiers or include a custom string to add meaning.
Would this be preferable over filling the common.h with long time gone
devices past identifiers that are overly specific to that platform or device? we
already have a few of them now.

Something like this:

led-lan-link {
function = LED_FUNCTION_LAN;
function-qualifier = "link-speed"; // NEW PROPERTY
color = <LED_COLOR_ID_GREEN>;
led-instance = "port5";
/* Result: green:lan-link-speed:port5 */
};

led-cellular-signal {
function = LED_FUNCTION_WLAN; // or new LED_FUNCTION_CELLULAR
function-qualifier = "signal-strength";
color = <LED_COLOR_ID_GREEN>;
led-instance = "modem0";
/* Result: green:wlan-signal-strength:modem0 */
};

// Network qualifiers
"link" // Cable connected
"activity" // Data transfer
"speed" // Link speed indication
"duplex" // Full/half duplex
"mesh" // Mesh node

// Cellular qualifiers
"signal" // Signal strength
"activity" // Data activity
"registered" // Registered to network
"roaming" // Roaming status

// Power qualifiers
"charging" // Battery charging
"low" // Low battery warning
"present" // Power source present

I'm just really trying to find a way to make the naming more descriptive and I'm
open to suggestions.

regards Jonathan Brophy