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: <CADvTj4qab272xTpZGRoPnCstufK_3e9CY99Og+2mey2co6u5dg@mail.gmail.com>
Date: Wed, 28 May 2025 15:45:40 -0600
From: James Hilliard <james.hilliard1@...il.com>
To: Andrew Lunn <andrew@...n.ch>
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

On Wed, May 28, 2025 at 3:29 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > > 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.

How is this better than just choosing the correct PHY based on the
efuse?

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

This is what I'm really trying to avoid since it requires special
handling in the bootloader and therefore will result in a lot of broken
systems since most people doing ports to H616 based boards will only
ever test against one PHY variant.

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

That's not really true IMO, mainline implements all sorts of workarounds
for various vendor hardware quicks/weirdness.

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

Sure, and I'm trying to do that here rather than do some super hacky
unmaintainable bootloader based device tree selector.

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

It won't here, because Allwinner doesn't care about non-BSP kernels.