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

[Jacek Anaszewski <jacek.anaszewski@gmail.com>]

On 12/29/25 13:30, Andriy Shevencho wrote:
> On Mon, Dec 29, 2025 at 12:16:17PM +0100, Jacek Anaszewski wrote:
>> On 12/28/25 19:22, Jonathan Brophy wrote:
> 
>>> 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.
> 
> 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