Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards

[Josua Mayer <josua@solid-run.com>]

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.