On Fri, Mar 10, 2023 at 10:37:25AM +0100, Linus Walleij wrote:

On Thu, Mar 9, 2023 at 4:22 PM Andrew Lunn [off-list ref] wrote:

quoted

As to 'how a certain trigger on a certain LED is going to associate
itself with, say, a certain port' is clearly a property of the
hardware, when offloading is supported. I've not seen a switch you can
arbitrarily assign LEDs to ports. The Marvell switches have the LED
registers within the port registers, for example, two LEDs per port.

Aha so there is an implicit HW dependency between the port and the
LED, that we just cannot see in the device tree. Okay, it makes sense.

Well, i would say the dependency is in the device tree, in that the
LEDs are described in the ports, not as a block of their own at a
higher level within the switch. And in some switches, they might
actually be a block of registers in there own space, rather than in
the port registers. But i still expect there is a fixed mapping
between LED and port.

I think there will be a day when a switch without LED controller appears,
but the system has a few LEDs for the ports connected to an
arbitrary GPIO controller, and then we will need this. But we have
not seen that yet :)

The microchip sparx5 might be going in that direction. It has what
looks like a reasonably generic sgpio controller:
drivers/pinctrl/pinctrl-microchip-sgpio.c

But this not just about switches. It is also plain NICs. And using
ledtrig-netdev, you could make your keyboard LED blink based on
network traffic etc. So yes, using a phandle to an LED could very well
be useful in the future.

   Andrew