[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251125214450.qeljlyt3d27zclfr@skbuf>
Date: Tue, 25 Nov 2025 23:44:50 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: 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>
Subject: Re: [PATCH net-next 1/9] dt-bindings: phy: rename
transmit-amplitude.yaml to phy-common-props.yaml
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@....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.
Powered by blists - more mailing lists