> > 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/ 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. 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. Andrew
