Message-ID: <CADvTj4pKsAYsm6pm0sgZgQ+AxriXH5_DLmF30g8rFd0FewGG6w@mail.gmail.com>
Date: Wed, 28 May 2025 13:10:38 -0600
From: James Hilliard <james.hilliard1@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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 12:34 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> 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).

Hmm, yeah, I had copied the convention used here
https://github.com/torvalds/linux/blob/v6.15/arch/arm64/boot/dts/ti/k3-j784s4-evm-quad-port-eth-exp1.dtso#L42-L43

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

Yeah, I noticed it wasn't commonly used for ethernet PHYs, but
I didn't see any other way to define multiple named "phy-handle"s
for ethernet PHYs so I tried to use a similar style to serdes.

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

Ah, I thought it was fairly clear in the patch descriptions/example
that this was a non-standard situation due to unusual hardware.

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

I was just pointing that out as an example of runtime autodetection
being something the kernel supports. To me it seems using existing
conventions like "phys" and "phy-names" is the least invasive way
to define phy's that need to be chosen at runtime.

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

I think a lot of ethernet drivers use phy_find_first() for phy scanning
as well so it's not limited to just stmmac AFAIU.

> Therefore, I
> don't think using it as a justification for more "autodetection"
> stands up.

If anything I think the i2c OF component probe functionality is
a much clearer example of precedent for DT integrated runtime
hardware detection since the purpose of that(supporting second
source components within the same device tree) is effectively
the same use case as this efuse based runtime hardware
detection.

Powered by blists - more mailing lists