Message-ID: <9c2518d8-a0ea-46ba-9069-999c2574cd24@bootlin.com>
Date: Wed, 26 Nov 2025 15:25:00 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Vladimir Oltean <vladimir.oltean@....com>, Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, devicetree@...r.kernel.org,
 linux-phy@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 Daniel Golle <daniel@...rotopia.org>,
 Horatiu Vultur <horatiu.vultur@...rochip.com>,
 Heiner Kallweit <hkallweit1@...il.com>, Russell King
 <linux@...linux.org.uk>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Vinod Koul <vkoul@...nel.org>,
 Kishon Vijay Abraham I <kishon@...nel.org>,
 Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Eric Woudstra <ericwouds@...il.com>, Marek Beh√∫n
 <kabel@...nel.org>, Lee Jones <lee@...nel.org>,
 Patrice Chotard <patrice.chotard@...s.st.com>,
 Holger Brunck <holger.brunck@...achienergy.com>
Subject: Re: [PATCH net-next 1/9] dt-bindings: phy: rename
 transmit-amplitude.yaml to phy-common-props.yaml

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

Powered by blists - more mailing lists