Re: [PATCH 10/21] net: phy: add X-Powers AC200 EPHY control driver

quoted

So what i'm trying to do with both of these is make it look more like
standard Linux building blocks.

If that is not possible, i would actually put all this code into the
PHY driver. You then have a regmap property to gain access to the I2C
registers.

I understand the goal of using standard Linux building blocks where they
fit, but I do not think folding these control paths into the common PHY
driver gives the right device model here.

The AC200 and AC300 expose the same Clause 22 PHY interface, but their
control functions are separate devices with different transports and
lifetimes. The AC200 control function is an MFD child accessed through
the parent I2C regmap. The AC300 control function is a separately
addressed non-PHY MDIO device. A regmap reference only describes the
AC200 transport; it does not represent the AC300 control device.

Folding both implementations into the common PHY driver would make that
driver manage AC200 MFD registers and resources as well as an AC300 MDIO
control endpoint. That would mix the package-specific control transports
with the otherwise common Clause 22 implementation.

Given how messy this hardware is, i doubt it is discoverable. We have
been pushing back on hacks to enable various things before probe in
order to make it discoverable. So you are going to end up putting IDs
in DT so that the driver probes without it being discovered. That
means you can put any ID you want in DT, and the driver. So you have
two different phy driver structs, two different probe functions, etc.

	Andrew