> I am a bit reluctant on the ambition to rely on configuration from sysfs > for the triggers, and I am also puzzled to how a certain trigger on a > certain LED is going to associate itself with, say, a certain port. Hi Linus There will need to be a device tree binding for the default trigger. That is what nearly all the rejected hacks so far have been about, write registers in the PHYs LEDs registers to put it into a specific mode. I don't see that part of the overall problem too problematic, apart from the old issue, is it describing configuration, not hardware. 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. > > I want to draw your attention to this recently merged patch series > from Hans de Goede: > https://lore.kernel.org/linux-leds/20230120114524.408368-1-hdegoede@xxxxxxxxxx/ > > This adds the devm_led_get() API which works similar to getting > regulators, clocks, GPIOs or any other resources. Interesting. Thanks for pointing this out. But i don't think it is of interest in our use case, which is hardware offload. For a purely software controlled LED, where the LED could be anywhere, devm_led_get() makes sense. But in our case, the LED is in a well defined place, either the MAC or the PHY, where it has access to the RX and TX packets, link status etc. So we don't have the problem of finding it in an arbitrary location. There is also one additional problem we have, both for MAC and PHY LEDs. The trigger is ledtrig-netdev. All trigger state revolves around a netdev. A DSA port is not a netdev. A PHY is not a netdev. Each of these three things have there own life cycle. Often, a PHY does not know what netdev it is associated to until the interface is opened, ie. ip link set eth0 up. But once it is associated, phylib knows this information, so can return it, without any additional configuration data in DT. A DSA switch port can be created before the netdev associated to it is created. But again, the DSA core does know the mapping between a netdev and a port. Using devm_led_get() does not gain us anything. Andrew
