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

[Jonathan Brophy]

>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