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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1b815a90-f50e-4bf5-8e43-2f4ac11f96bc@lunn.ch>
Date: Wed, 26 Nov 2025 15:09:43 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <vladimir.oltean@....com>
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>,
	Maxime Chevallier <maxime.chevallier@...tlin.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

> All I'm trying to say is that we're missing an OF node to describe
> mv88e6xxx PCS electrical properties, because otherwise, it collides with
> case (1). My note regarding "phys" was just a guess that the "phy-handle"
> may have been mistaken for the port's SerDes PHY. Although there is a
> chance Holger knew what he was doing. In any case, I think we need to
> sort this one way or another, leaving the phy-handle logic a discouraged
> fallback path.
> 
> That being said, I'm not exactly an expert in determining _how_ we could
> best retrofit SerDes/PCS OF nodes on top of the mv88e6xxx bindings.
> It depends on how many SerDes ports there are in these switches
> architecturally, and what is their register access method, so it would
> need to be handled on a case-by-case basis rather than one-size-fits-all.
> PCS node in port node could be a starting point, I guess, but I don't
> know if it would work.

I would more likely have a PCS container node and then list each PCS
within it, using reg as the MDIO bus address. The 6352 has one PCS,
but depending on configuration port 5 or port 6 can make use of it. (I
might have the numbers wrong, but the principle is correct). Some of
the other switches have more PCSs but with a fixed mapping to
ports. And the 6390X has 2x 10G PCS. But you can take this 10G PCS and
split it into 2x 5G. And you can take those 5G PCS and split it into
two to give a PCS which can do 1/2.5G.

Given this flexibility, putting the PCS in the port would probably be
a bad idea.

	Andrew