On Sun, Dec 28, 2025 at 07:14:09PM +0000, Jonathan Brophy wrote:
> >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?

...

> **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)

Ah, forgot to comment on this. ACPI incorporates the way of key=value
properties in the similar way DT does. So it's not a good point.

> 2. Adds complexity to LED core for every driver
> 3. Requires userspace policy to parse and create symlinks

This is what udev is for.

> 4. Still depends on non-deterministic suffix

Same as #3.

So, this leaves us only #2. Which is a weak argument in my opinion.

> The instance identifier solves this with much less effort.

But as I already replied, your approach is also okay to me.

-- 
With Best Regards,
Andy Shevchenko