On Fri, Mar 10, 2023 at 10:37:25AM +0100, Linus Walleij wrote: > On Thu, Mar 9, 2023 at 4:22 PM Andrew Lunn <andrew@xxxxxxx> wrote: > > > 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
