Hi Andrew and phylib/phylink maintainers in general,

On Tue, Aug 22, 2023 at 04:10:45PM +0200, Andrew Lunn wrote:

For C22 PHYs, the ID registers are only used to ask user space to load
a driver which supports that ID, and then used to match a device to a
driver. We often say that if the ID registers don't actually contain
an ID, or the wrong ID, use ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$
to let the subsystem know the correct ID.

The device you are trying to support has the same problem, invalid
IDs, but its C45.

C45 IDs however work slightly differently. An C45 package can have
multiple devices in it, up to 32. Each device has its own ID
registers. So there can be up to 32 different IDs for one package. The
core will try to determine which of the 32 devices are actually in the
package, and if they are, what the ID is. It then asks user space to
load a driver for all the IDs it finds. And when matching devices to
drivers, it sees if any of the ID of the package matches the IDs the
driver says it supports. If a match is found, that one driver is
expected to drive all the devices in that one package.

I don't see a need for ethernet-phy-ieee802.3-c45-idXXXX.XXXX,
ethernet-phy-ieee802.3-idXXXX.XXXX should be sufficient, since all you
are doing it matching the ID against the driver. That matching does
not differ between C22 and C45. 

Saying "ethernet-phy-ieee802.3-c45" might be useful, because at the
moment we have a mixup between C45 register space and C45 bus
transactions. The drive is free to access C22 and/or C45 registers,
since it should know what the device actually has. But some of the
core might get the wrong idea without "ethernet-phy-ieee802.3-c45".

O.K, that the background now:

quoted

First: Compatible strings per C45 MMD? Drivers per C45 MMD

So far, nobody has needed that. All current drivers are package
drivers, they drive all the devices in the package. At least for a
PHY, there is close integration between devices in a package. Russell
has commented that the Marvell 10G PHY does appear to contain a number
of licensed devices, but so far, we have not noticed the same licensed
device used by multiple vendors. So there has not been any need to
reuse code.

However, it sounds like the package you are trying to support does
contain multiple independent devices. So from an architecture
perspective, having multiple drivers would make sense, even if there
is no reuse. But are the devices PHY? Everything i've said so far
applies to PHYs. It does not apply to a PCS, etc.

	Andrew

I don't know if the devices qualify as phy_device structures according
to the opinion of the maintainers, and that is one of the fundamental
aspects I would like this RFC to clarify, before I proceed to request
NXP to allocate a new PHY ID that I can put in the compatible string.

If the backplane AN/LT block is not a phy_device structure, my
imagination will need a bit of help on how to integrate it, as a raw
mdio_device, with phylink or with the consumer MAC drivers directly.