Am 22.03.24 um 14:11 schrieb Andrew Lunn: >>> Sorry, but no. List the LEDs in the PHY node, and they can then be >>> controlled via /sys/class/leds. >> May I ask more precisely the motivation? >> Does this replace the phy's builtin automatic led control? >>> arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. >> I will investigate it. >> >> My main motivation for tweaking the led controls was to make them all consistent across the two boards: >> - LEDs under control of PHYs on cpu mdio bus >> - LEDs under control of ethernet switch on mdio bus >> - LEDs under control of ethernet phy on external mdio bus behind ethernet switch >> >> It looks as if the marvell phy driver supports led subnodes, >> The switch driver does not. > https://lwn.net/Articles/965775/ Great! > > There has been quite a bit of interest in mv88e6xxx driver support, so > i expect support for other families outside of 6352 will be added > after it has been merged, and it is not difficult code to write. > >> Finally one phy can only be written to but not read, >> the cpu can never know its link state. > O.K. That one cannot use the LED infrastructure in a meaningful way. > >> So I prefer (for the Clearfog Pro) board to explicitly use the phys >> autonomous management of LEDs. >> Is that still possible if I added led subnodes? > You can combine both. The horrible marvell,reg-init will be applied > first. The generic LED code will then take over controlling the LEDs. I (currently) can't put in the led node e.g. linux,default-trigger = "link100|link1000|tx|rx"; Right? > > For the discrete PHYs, the generic LED code can make use of the > hardware offload support to read back the hardware configuration and > configure itself to match. The switch code is missing hardware offload > at the moment. So it cannot read back the current > configuration. However, it is simple code to add, and the discrete > code is a good example to follow. > > marvell,reg-init is not going to go away, because of backwards > compatibility with old DT blobs. But in general, i expect all vendor > proprietary methods of configuring LEDs to be deprecated and replaced > with the vendor neutral /sys/class/leds. Sounds good.
