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

[Vladimir Oltean]

On Tue, Nov 25, 2025 at 10:19:11PM +0100, Andrew Lunn wrote:
> On Sat, Nov 22, 2025 at 09:33:33PM +0200, Vladimir Oltean wrote:
> > I would like to add more properties similar to tx-p2p-microvolt, and I
> > don't think it makes sense to create one schema for each such property
> > (transmit-amplitude.yaml, lane-polarity.yaml, transmit-equalization.yaml
> > etc).
> > 
> > Instead, let's rename to phy-common-props.yaml, which makes it a more
> > adequate host schema for all the above properties.
> > 
> > Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>
> > ---
> >  .../{transmit-amplitude.yaml => phy-common-props.yaml}    | 8 ++++----
> 
> So there is nothing currently referencing this file?

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.

I note that referencing an Ethernet PHY is done using "phy-handle", a
generic PHY using "phys", and that the two are not the same. A SerDes is
a generic PHY but not an Ethernet PHY.

I looked again through the most lengthy discussion on this patch:
https://lore.kernel.org/netdev/20211207190730.3076-2-holger.brunck@hitachienergy.com/
but did not see this aspect being pointed out.