linux-kernel - Re: [PATCH v2 1/3] net: stmmac: allow drivers to explicitly select PHY device

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]

Message-ID: <0bf48878-a3d0-455c-9110-5c67d29073c9@lunn.ch>
Date: Wed, 28 May 2025 23:29:23 +0200
From: Andrew Lunn <andrew@...n.ch>
To: James Hilliard <james.hilliard1@...il.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, wens@...e.org,
	netdev@...r.kernel.org, linux-sunxi@...ts.linux.dev,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Furong Xu <0x1207@...il.com>,
	Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] net: stmmac: allow drivers to explicitly select
 PHY device

> > Describe the one PHY which actually exists in device tree for the
> > board, and point to it using phy-handle. No runtime detection, just
> > correctly describe the hardware.
> 
> But the boards randomly contain SoC's with different PHY's so we
> have to support both variants.

You have two .dts files, resulting in two .dtb files, which are 95%
identical, but import a different .dtsi file for the PHY.

You can test if the correct .dtb blob is used by checking the fuse. If
it is wrong, you can give a hint what .dtb should be used.

Or, as Russell suggested, you give the bootloader both .dtb blobs, and
it can pick the correct one to pass to the kernel. Or the bootloader
can patch the .dtb blob to make it fit the hardware.

> > Do you have examples of boards where the SoC variant changed during
> > the boards production life?
> 
> Yes, the boards I'm working for example, but this is likely an issue for
> other boards as well(vendor BSP auto detects PHY variants):
> https://www.zeusbtc.com/ASIC-Miner-Repair/Parts-Tools-Details.asp?ID=1139

Mainline generally does not care what vendors do, because they often
do horrible things. Which is O.K, it is open source, they can do what
they want in their fork of the kernel.

But for Mainline, we expect a high level of quality, and a uniform way
of doing things.

This can also act as push back on SoC vendors, for doing silly things
like changing the PHY within a SoC without changing its name/number.

	Andrew