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

Jacek Anaszewski
2025-12-29T11:16:21Z

Hi Jonathan,

On 12/28/25 19:22, Jonathan Brophy wrote:
> From: Jonathan Brophy <professor_jonny@hotmail.com>
>
> This patch series introduces an optional "led-instance" device tree property
> to address non-deterministic LED naming when multiple LEDs share the same
> function and color.
>
> Currently, the LED core appends numerical suffixes (_1, _2, etc.) based on
> registration order when duplicate function:color combinations exist. This
> creates several problems:
>
> 1. **Non-deterministic naming**: Registration order determines suffix values,
> which can change across boots due to probe ordering, async initialization,
> or module load order.
>
> 2. **Non-semantic identifiers**: Names like "lan:green_23" provide no
> indication of which physical LED or subsystem they represent.
>
> 3. **Breaks userspace automation**: Network management tools, LED control
> daemons, and hardware monitoring cannot reliably identify LEDs.
>
> 4. **Ambiguous numbering**: "lan:green_23" could be mistaken for LAN port 23
> when it may actually be the 23rd registered LED of any port.
>
> 5. **Namespace pollution**: The alternative of adding vendor-specific function
> names (LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...) pollutes the
> function namespace. The instance identifier keeps standard functions clean
> while allowing contextual differentiation.
>
> 6. **Breaks naming convention**: The _1, _2 suffix was intended only as a
> collision avoidance workaround, but has become the de facto standard for
> hardware with multiple identical LEDs.
>
> **Example: 48-port network switch**
>
> Current behavior (non-deterministic):
> /sys/class/leds/lan:green ← Port 0? Unknown
> /sys/class/leds/lan:green_1 ← Could be any port
> /sys/class/leds/lan:green_2 ← Could be any port
> ...
> /sys/class/leds/lan:green_47 ← Could be port 1 due to probe order
>
> Proposed behavior (deterministic):
> /sys/class/leds/lan:green:port0 ← Always port 0
> /sys/class/leds/lan:green:port1 ← Always port 1
> /sys/class/leds/lan:green:port2 ← Always port 2
> ...
> /sys/class/leds/lan:green:port47 ← Always port 47
>
> **Example: Multi-domain power indicators**
>
> Current behavior (non-deterministic):
> /sys/class/leds/power:red ← Which power source?
> /sys/class/leds/power:red_1 ← Which power source?
> /sys/class/leds/power:red_2 ← Which power source?
>
> Proposed behavior (deterministic):
> /sys/class/leds/power:red:mains ← Mains power indicator
> /sys/class/leds/power:red:battery ← Battery power indicator
> /sys/class/leds/power:red:usb ← USB power indicator
>
> **Design principles:**
>
> - Backward compatible: Instance identifier is optional
> - Extends existing convention: function:color becomes function:color:instance
> - Follows kernel precedent: Similar to eth0/eth1, gpio0/gpio1 naming patterns
> - Ignored with deprecated "label" property: Avoids conflicts with legacy code
>
> **Alternative solutions considered:**
>
> 1. function-enumerator: Only supports numbers (0, 1, 2), producing names like
> "lan:green-0" which are still non-semantic. The 48-port switch needs "port0"
> to match physical port labels.

I think that we have currently everything in place to address the issue
you're trying to solve with this patch. Just introduce dedicated
function like LAN_PORT, and exploit function-enumerator.

--
Best regards,
Jacek Anaszewski