Re: [PATCH 00/21] net: phy: add X-Powers AC200/AC300 EPHY support

On Mon, Aug 3, 2026 at 7:26 AM Andre Przywara [off-list ref] wrote:

Hi James,

thanks for sending this to the list, but as Andrew already mentioned:
this is quite a beast, and would need to be broken down.
Jernej and I created some patches just for the AC200 PHY on the H6,
which Jernej recently revived, and IIUC, wanted to send to the list.
This would probably be a more workable route: start easy, then add
support for more SoCs (H616 depends on the WIP PWM driver) and more
variants (AC300) later.

Well, I wanted to validate that the overall driver design is suitable for
the H616 which has to support both PHY variants at runtime effectively
since that is the most complex use case, I also don't have a H6 board
to test with myself at the moment. I think being able to see a more
complete implementation like this is helpful as it can better inform how
we can tie the different control interfaces to the link PHY in a way that
works for the more complex H616 case.

Which also brings me to some attribution questions: If I understand
correctly, this has been written mostly by some LLM? I think you would
need at least to disclose that, if not even add an official tag?

Some patches were, sure, my understanding is that it's not required to
explicitly call that out but I can add more info if that helps, this was
tested/validated using a heavily automated hardware in the loop
testbench setup on an AC200 and AC300 variant H616 board.

Also I wonder how this relates to the patches floating around for a
while already: https://github.com/jernejsk/linux-1/commits/ac200-v4.
This branch is relatively new, but the ac200-v3 branch for instance is
much older.

Yeah, parts of this are loosely based off of some existing patches that
were floating around like those, although it has diverged quite a bit as
well since this series is designed to handle both phy variants.

I guess I should link to some of the earlier work in the cover letter?

On 8/3/26 07:14, James Hilliard wrote:

quoted

The Allwinner H616/H618 secondary EMAC is commonly connected to a Fast
Ethernet PHY in an X-Powers AC200 or AC300 companion package.  The two
packages expose the same link PHY ID and largely compatible link-side
registers, but require different control paths before those registers can
be accessed: AC200 is initialized through its I2C MFD, while AC300 uses a
non-PHY Clause 22 control endpoint.

Some H616-family products were shipped with either package under the same
board identity.  For those systems, this series uses a SID NVMEM field to
select the control provider at run time.  With CONFIG_OF_DYNAMIC, the link
PHY enables only the selected fail-needs-probe provider, so an AC300 board

Just to bring that shallow discussion we had on IRC to the list: I
wonder if this is the right solution? Alternatively I was wondering if
just patching the DT in U-Boot would simplify things, and also help
other DT users like *BSD or U-Boot (proper) itself, to not boil the
ocean, but just allowing them to follow a standard DT description.

This can be used either way, CONFIG_OF_DYNAMIC isn't a hard
dependency with this design, aside from adding CONFIG_OF_DYNAMIC
support for mdio the dynamic enablement of the correct phy control
drivers is relatively simple with this architecture.