Message-ID: <CADvTj4qyRRCSnvvYHLvTq73P0YOjqZ=Z7kyjPMm206ezMePTpQ@mail.gmail.com>
Date: Wed, 28 May 2025 11:25:20 -0600
From: James Hilliard <james.hilliard1@...il.com>
To: wens@...e.org, Andrew Lunn <andrew@...n.ch>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, 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 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.

https://github.com/torvalds/linux/blob/v6.15/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c#L646-L673

> The other thing is that there are no distinguishing identifiers for a
> device tree match for the swap-in variants at the board / device level.
> Though I do have something that does DT fixups in the kernel for IDs
> passed over by the firmware. There are other reasons for this arrangement,
> one being that the firmware is not easily upgradable.
>
> ChenYu
>
> > You are talking about some form of chiplet like component within the
> > SoC package. It is not easy to replace, and not expected to be
> > replaced.
> >
> > Different uses cases altogether.
> >
> > What i think we will end up with is the base SoC .dtsi file, and two
> > additional .dtsi files describing the two PHY variants.

I think having a single PHY .dtsi for both here is ideal if we can
do runtime detection, since it's difficult to know which potential
variants of PHY various devices shipped with, in our case we
have access to enough hardware to determine that we have
both variants but for other devices most developers will likely
only have access to one PHY variant even if hardware at various
points in time may have shipped with both variants.

IMO without runtime detection this will likely be a major footgun
for anyone trying to add ethernet support to H616 boards as they
will have difficulty testing on hardware they don't have. If we provide
a single .dtsi that implements the autodetection correctly then they
will simply be able to include that and the hardware will then likely
function on both variants automatically by including the single .dtsi
file.

Requiring the bootloader to modify the DT adds a good bit of
complexity and will be difficult for most developers to test as
many will not have access to hardware with both PHY variants.

Powered by blists - more mailing lists