Re: [PATCH net-next 1/9] dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml

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

+Maxime, Holger
thread at https://lore.kernel.org/netdev/20251122193341.332324-2-vladimir.oltean@nxp.com/

On Tue, Nov 25, 2025 at 11:33:09PM +0100, Andrew Lunn wrote:
> > Yeah, although as things currently stand, I'd say that is the lesser of
> > problems. The only user (mv88e6xxx) does something strange: it says it
> > wants to configure the TX amplitude of SerDes ports, but instead follows
> > the phy-handle and applies the amplitude specified in that node.
> > 
> > I tried to mentally follow how things would work in 2 cases:
> > 1. PHY referenced by phy-handle is internal, then by definition it's not
> >    a SerDes port.
> > 2. PHY referenced by phy-handle is external, then the mv88e6xxx driver
> >    looks at what is essentially a device tree description of the PHY's
> >    TX, and applies that as a mirror image to the local SerDes' TX.
> > 
> > I think the logic is used in mv88e6xxx through case #2, i.e. we
> > externalize the mv88e6xxx SerDes electrical properties to an unrelated
> > OF node, the connected Ethernet PHY.
> 
> My understanding of the code is the same, #2. Although i would
> probably not say it is an unrelated node. I expect the PHY is on the
> other end of the SERDES link which is having the TX amplitudes
> set. This clearly will not work if there is an SFP cage on the other
> end, but it does for an SGMII PHY.

It is unrelated in the sense that the SGMII PHY is a different kernel
object, and the mv88e6xxx is polluting its OF node with properties which
it then interprets as its own, when the PHY driver may have wanted to
configure its SGMII TX amplitude too, via those same generic properties.

> I guess this code is from before the time Russell converted the
> mv88e6xxx SERDES code into PCS drivers. The register being set is
> within the PCS register set.  The mv88e6xxx also does not make use of
> generic phys to represent the SERDES part of the PCS. So there is no
> phys phandle to follow since there is no phy.

In my view, the phy-common-props.yaml are supposed to be applicable to either:
(1) a network PHY with SerDes host-side connection (I suppose the media
    side electrical properties would be covered by Maxime's phy_port
    work - Maxime, please confirm).
(2) a phylink_pcs with SerDes registers within the same register set
(3) a generic PHY

My patch 8/9 (net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and
"airoha,pnswap-tx") is an example of case (1) for polarities. Also, for
example, at least Aquantia Gen3 PHYs (AQR111, AQR112) have a (not very
well documented) "SerDes Lane 0 Amplitude" field in the PHY XS Receive
(XAUI TX) Reserved Vendor Provisioning 4 register (address 4.E413).

My patch 7/9 (net: pcs: xpcs: allow lane polarity inversion) is an
example of case (2).

I haven't submitted an example of case (3) yet, but the Lynx PCS and
Lynx SerDes would fall into that category. The PCS would be free of
describing electrical properties, and those would go to the generic PHY
(SerDes).

All I'm trying to say is that we're missing an OF node to describe
mv88e6xxx PCS electrical properties, because otherwise, it collides with
case (1). My note regarding "phys" was just a guess that the "phy-handle"
may have been mistaken for the port's SerDes PHY. Although there is a
chance Holger knew what he was doing. In any case, I think we need to
sort this one way or another, leaving the phy-handle logic a discouraged
fallback path.

That being said, I'm not exactly an expert in determining _how_ we could
best retrofit SerDes/PCS OF nodes on top of the mv88e6xxx bindings.
It depends on how many SerDes ports there are in these switches
architecturally, and what is their register access method, so it would
need to be handled on a case-by-case basis rather than one-size-fits-all.
PCS node in port node could be a starting point, I guess, but I don't
know if it would work.

For SJA1105 and the XPCS, I thought the best course of action would be
to create a "regs" container node in the switch, under which we'd have
"ethernet-pcs" children, but that seems to be problematic in its own
ways, due to how MFD is seemingly abused to make that work:
https://lore.kernel.org/netdev/20251118190530.580267-15-vladimir.oltean@nxp.com/