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