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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 22 Mar 2024 15:38:30 +0000
From: Josua Mayer <josua@...id-run.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Gregory Clement <gregory.clement@...tlin.com>, Sebastian Hesselbarth
	<sebastian.hesselbarth@...il.com>, Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley
	<conor+dt@...nel.org>, Yazan Shhady <yazan.shhady@...id-run.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som
 and clearfog boards

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.