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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aVJ0c3injbP7yRIJ@smile.fi.intel.com>
Date: Mon, 29 Dec 2025 14:30:43 +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 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?

-- 
With Best Regards,
Andy Shevchenko