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

[Maxime Chevallier]

Hi,

On 26/11/2025 08:26, Vladimir Oltean wrote:
> +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).

True, but we could definitely conceive applying phy-common-props.yaml on
the media-side as well :) I don't have a use-case for it right now
though, and we don't yet have detailed descriptions of the electrical
properties.

Maxime