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

Jonathan Brophy
2025-12-28T18:23:22Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 3842 bytes --]

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.

2. Deprecated "label" property: Being actively removed from LED bindings. New
code should not rely on deprecated APIs.

3. Different function names: LED_FUNCTION_LAN_PORT0, LED_FUNCTION_LAN_PORT1...
This pollutes the function namespace with hardware-specific combinations.

This RFC seeks feedback on:
- Property naming: "led-instance" vs "led-subsystem" vs "led-context"
- Implementation approach
- Additional use cases to document

Jonathan Brophy (2):
leds: core: Add support for led-instance property
dt-bindings: leds: common: Add led-instance property

.../devicetree/bindings/leds/common.yaml | 93 +++++++++++++++++++
drivers/leds/led-core.c | 43 +++++++--
2 files changed, 126 insertions(+), 10 deletions(-)

--
2.43.0