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:
 <DS0PR84MB3746809655135654882AF9D39FBEA@DS0PR84MB3746.NAMPRD84.PROD.OUTLOOK.COM>
Date: Sun, 28 Dec 2025 19:14:09 +0000
From: Jonathan Brophy <Professor_jonny@...mail.com>
To: Andriy Shevencho <andriy.shevchenko@...ux.intel.com>, Jonathan Brophy
	<professorjonny98@...il.com>
CC: lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>, 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" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [RFC PATCH 0/2] leds: Add optional instance identifier for
 deterministic naming

>Hmm... I think the research missed the udev + sysfs approach as done for the

>networking devices. Hence the question: do we have enough data in sysfs for

>leds to understand their HW connections / semantics?

>--

>With Best Regards,

>Andy Shevchenko

I looked at that also but I don't see a way of it working with the current led attributes:

**Current LED sysfs attributes:**

For a typical LED, we have:
  /sys/class/leds/lan:green/
    ├── brightness
    ├── max_brightness
    ├── trigger
    └── device -> ../../../gpio-leds  (generic, not port-specific)

The problem is that **there's no stable identifier** that maps to the hardware:
- The device symlink points to the LED controller (e.g., gpio-leds), not the
  specific port/function
- There's no DT path or hardware identifier exposed
- Multiple identical LEDs (lan:green, lan:green_1, lan:green_2) all have
  identical sysfs attributes except their names

I don't think udev can't help here either:

Network devices work because they have unique identifiers:
  - MAC addresses (globally unique)
  - PCI bus addresses (stable per-slot)
  - Device tree paths (but not exposed for LEDs)

LEDs in a run of the mill 48-port switch generally have:
  - Same GPIO controller
  - Same function (LED_FUNCTION_LAN)
  - Same color (LED_COLOR_ID_GREEN)
  - Same trigger options
  - **Nothing unique** except the name

**What we'd need for udev to work:**

We'd need to expose something like:
  /sys/class/leds/lan:green_23/dt_path -> /leds/led-port23
  /sys/class/leds/lan:green_23/hardware_id

But this has problems:
1. Not all platforms use DT (ACPI systems)
2. Adds complexity to LED core for every driver
3. Requires userspace policy to parse and create symlinks
4. Still depends on non-deterministic suffix

The instance identifier solves this with much less effort.

Instead of:
  1. Kernel creates "lan:green_23" (non-deterministic)
  2. Kernel exposes DT path in sysfs
  3. Udev reads DT path
  4. Udev creates symlink "lan-port23" -> "lan:green_23"
  5. Userspace uses symlink

We get:
  1. Kernel creates "lan:green:port23" (deterministic, from DT)
  2. Userspace uses it directly

This is simpler, works on non-DT platforms, and follows the existing
function:color naming convention by extending it rather than working around it.

**Precedent:**

The networking subsystem itself had to solve this with predictable interface
names (enp3s0) because MAC addresses aren't in DT and PCI enumeration order
can change.
With this patch we're solving the same problem, but for LEDs the solution is
simpler: put the identifier in the name from the start.

I don't know of another suitable way to make it work without much change
and from my research it really does not bring much to the table and adds a lot
of complexity when there is a simple solution.

Regards
Jonathan Brophy