Thread (36 messages) 36 messages, 10 authors, 2025-12-04

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

From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: 2025-11-26 14:25:14
Also in: linux-arm-kernel, linux-devicetree, linux-mediatek, linux-phy, lkml

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/ (local)

On Tue, Nov 25, 2025 at 11:33:09PM +0100, Andrew Lunn wrote:
quoted
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help