Message-ID: <36bb7d51-2fca-4d06-b78d-e411f67ecf56@lunn.ch>
Date:   Tue, 22 Aug 2023 16:10:45 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Rob Herring <robh@...nel.org>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-phy@...ts.infradead.org,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Madalin Bucur <madalin.bucur@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Camelia Groza <camelia.groza@....com>,
        Li Yang <leoyang.li@....com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor@...nel.org>,
        Sean Anderson <sean.anderson@...o.com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Vinod Koul <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>
Subject: Re: [RFC PATCH net-next 8/8] dt-bindings: net: fsl,backplane-anlt:
 new binding document

> > O.K, not ideal. For C22, you could just put the ID values in the
> > compatible, which is enough to get a driver loaded which supports that
> > ID. But somebody recently commented that that does not work for C45. I
> > assume NXP has an OUI, and could allocate an ID to this device in
> > retrospect. So maybe it makes sense to make C45 work with an ID in the
> > compatible? And get the driver loaded that way?
> > 
> > 	Andrew
> 
> There are 2 clarification questions that I can think of right now.
> Maybe more later.
> 
> First: Compatible strings per C45 MMD? Drivers per C45 MMD? Is there
> supposed to be an interest in that? I might end up needing it (see the
> problem description in the cover letter, with PCS and AN/LT block merged
> into the same MDIO address, but responding to separate MMDs)
> 
> Second: Suppose I add something like "ethernet-phy-ieee802.3-c45-idXXXX.XXXX".
> Do I replace just this with that:
> 
> compatible = "fsl,lx2160a-backplane-anlt", "ethernet-phy-ieee802.3-c45";
> 
> or also this?
> 
> compatible = "fsl,lx2160a-secondary-anlt";
> 
> 
> I suppose it would be just the first one, but going that route would IMO
> just increase the dissonance between the description of primary and
> secondary AN/LT blocks. They're the same IP blocks, don't they also have
> the same fake PHY ID?

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

Powered by blists - more mailing lists