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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aVKT7PsPTzRFCuOu@smile.fi.intel.com>
Date: Mon, 29 Dec 2025 16:45:00 +0200
From: Andriy Shevencho <andriy.shevchenko@...ux.intel.com>
To: Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc: Jonathan Brophy <professorjonny98@...il.com>,
	lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>,
	Jonathan Brophy <professor_jonny@...mail.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Radoslav Tsvetkov <rtsvetkov@...dotech.eu>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-leds@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] leds: Add optional instance identifier for
 deterministic naming

On Mon, Dec 29, 2025 at 03:28:20PM +0100, Jacek Anaszewski wrote:
> 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.

Ah, that's nice!

-- 
With Best Regards,
Andy Shevchenko