On Wed, May 28, 2025 at 9:25 PM Andrew Lunn [off-list ref] wrote:

On Wed, May 28, 2025 at 05:57:38AM -0600, James Hilliard wrote:

quoted

On Wed, May 28, 2025 at 1:53 AM Russell King (Oracle)
[off-list ref] wrote:

quoted

On Tue, May 27, 2025 at 02:37:03PM -0600, James Hilliard wrote:

quoted

On Tue, May 27, 2025 at 2:30 PM Andrew Lunn [off-list ref] wrote:

quoted

quoted

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.

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.

        Andrew