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

The AC200 Datasheet V1.1 and AC300 User Manual V1.0 block diagrams show
effectively the same EPHY organization: MII/RMII, auto-negotiation,
Auto-MDIX, 10/100 transmit and receive PCS/PMA blocks, LED and
clock/reset logic, a PLL, and the EPHY analog front end. Both variants
also report PHY ID 0x00441400, and testing shows compatible link-side
paged registers and behavior.

What differs is the surrounding control path.

Which is still part of the PHY, needs driver code, and so should be
part of the PHY driver. 

AC200 is configured
through its RSB/TWI-backed MFD registers, while AC300 has a separate
non-PHY MDIO control endpoint.

Which is an implementation detail.

I do not think the control-provider reference is artificial. It
describes a real functional dependency: the Clause 22 endpoint cannot
be accessed until the selected package-specific control block has
powered, calibrated and configured it.

Nothing too special here. There are PHYs which do this, in the PHY
driver.

I also do not think a bootloader fixup should be the only supported
selection mechanism. Boards using the same compatible have shipped with
either package, and the SID field provides an authoritative package
selector which Linux can read directly. Handling that selector in Linux
avoids making support depend on a particular bootloader implementation.

There is a trade off here. If the hardware design is just ugly, badly
thought out, poorly executed, not following the industries norms, we
want to push back on the hardware vendor to make the next version
better. Until that improved version comes out, either the vendor crap
driver should be used, not Mainline, or we try to hide away the issues
in the bootloader. A vendor which actually cares will improve, they
know what Mainline means. And for vendors which don't care, why should
Mainline care, especially if the issues can be pushed to the
bootloader.

We don't want to mess up core Linux code to handle one broken device,
that just makes ongoing Maintenance more expensive for everybody.

A bootloader fixup remains compatible with this design. If firmware
enables only the correct provider, the fixed-description path is used
and Linux does not need to change the tree. Runtime selection is used
when firmware leaves the package variant unresolved.

So i would not try to fix up the unresolved situation, just do a
dev_error(dev, "Please upgrade your bootloader"); and return -ENODEV.

	Andrew