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 14:11:06 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Josua Mayer <josua@...id-run.com>
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

> > 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