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

[James Hilliard <james.hilliard1@gmail.com>]

On Wed, May 28, 2025 at 1:53 AM Russell King (Oracle)
<linux@armlinux.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@lunn.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

There's already a good bit of mdio autodetection code like
that which scans mdio buses for PHY ID's in stmmac. To me
this is just allowing for device specific autodetection logic, it's
not like we don't already have a good bit of generic PHY auto
detection code in the kernel already.

> I don't think that abusing "phys" is a good idea.
>
> It's quite normal for the boot loader to fix up the device tree
> according to the hardware - for example, adding the actual memory
> location and sizes that are present, adding reserved memory regions,
> etc. I don't see why you couldn't detect the differences and have
> the boot loader patch the device tree appropriately.

I mean, sure, that's technically possible, it just seems like it's
not the best fit option here since there seems to be no real
reason this sort of autodetection can't be handled in the
kernel itself.