Re: [RFC PATCH net-next 8/8] dt-bindings: net: fsl,backplane-anlt: new binding document

[Vladimir Oltean <vladimir.oltean@nxp.com>]

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:
> 
> > 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.