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: <aDdXRPD2NpiZMsfZ@shell.armlinux.org.uk>
Date: Wed, 28 May 2025 19:34:44 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: James Hilliard <james.hilliard1@...il.com>
Cc: wens@...e.org, Andrew Lunn <andrew@...n.ch>, 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 11:25:20AM -0600, James Hilliard wrote:
> On Wed, May 28, 2025 at 8:12 AM Chen-Yu Tsai <wens@...e.org> wrote:
> >
> > On Wed, May 28, 2025 at 9:25 PM Andrew Lunn <andrew@...n.ch> wrote:
> > >
> > > On Wed, May 28, 2025 at 05:57:38AM -0600, James Hilliard wrote:
> > > > On Wed, May 28, 2025 at 1:53 AM Russell King (Oracle)
> > > > <linux@...linux.org.uk> wrote:
> > > > >
> > > > > On Tue, May 27, 2025 at 02:37:03PM -0600, James Hilliard wrote:
> > > > > > On Tue, May 27, 2025 at 2:30 PM Andrew Lunn <andrew@...n.ch> wrote:
> > > > > > >
> > > > > > > > Sure, that may make sense to do as well, but I still don't see
> > > > > > > > how that impacts the need to runtime select the PHY which
> > > > > > > > is configured for the correct MFD.
> > > > > > >
> > > > > > > If you know what variant you have, you only include the one PHY you
> > > > > > > actually have, and phy-handle points to it, just as normal. No runtime
> > > > > > > selection.
> > > > > >
> > > > > > Oh, so here's the issue, we have both PHY variants, older hardware
> > > > > > generally has AC200 PHY's while newer ships AC300 PHY's, but
> > > > > > when I surveyed our deployed hardware using these boards many
> > > > > > systems of similar age would randomly mix AC200 and AC300 PHY's.
> > > > > >
> > > > > > It appears there was a fairly long transition period where both variants
> > > > > > were being shipped.
> > > > >
> > > > > Given that DT is supposed to describe the hardware that is being run on,
> > > > > it should _describe_ _the_ _hardware_ that the kernel is being run on.
> > > > >
> > > > > That means not enumerating all possibilities in DT and then having magic
> > > > > in the kernel to select the right variant. That means having a correct
> > > > > description in DT for the kernel to use.
> > > >
> > > > The approach I'm using is IMO quite similar to say other hardware
> > > > variant runtime detection DT features like this:
> > > > https://github.com/torvalds/linux/commit/157ce8f381efe264933e9366db828d845bade3a1
> > >
> > > That is for things link a HAT on a RPi. It is something which is easy
> > > to replace, and is expected to be replaced.
> >
> > Actually it's for second sourced components that are modules _within_
> > the device (a tablet or a laptop) that get swapped in at the factory.
> > Definitely not something easy to replace and not expected to be replaced
> > by the end user.
> 
> Yeah, to me it seems like the PHY situation is similar, it's not replaceable
> due to being copackaged, it seems the vendor just switched over to a
> second source for the PHY partway through the production run without
> distinguishing different SoC variants with new model numbers.
> 
> Keep in mind stmmac itself implements mdio PHY scanning already,
> which is a form of runtime PHY autodetection, so I don't really see
> how doing nvmem/efuse based PHY autodetection is all that different
> from that as both are forms of PHY runtime autodetection.

What is different is using "phys" and "phy-names" which historically
has never been used for ethernet PHYs. These have been used for serdes
PHYs (e.g. multi-protocol PHYs that support PCIe, SATA, and ethernet
protocols but do not provide ethernet PHY capability).

Historically, "phys" and "phy-names" have been the domain of
drivers/phy and not drivers/net/phy. drivers/net/phy PHYs have
been described using "phy-handle".

So, you're deviating from the common usage pattern, and I'm not sure
whether that has been made clear to the DT maintainers that that is
what is going on in this patch series.

As for the PHY scanning is a driver implementation issue; it doesn't
have any effect on device tree, it doesn't "abuse" DT properties to
do so. The PHY scanning is likely historical, probably from times
where the stmmac platform data was provided by board files (thus
having the first detected PHY made things simpler.) Therefore, I
don't think using it as a justification for more "autodetection"
stands up.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!