Message-ID: <176486478133.1579282.8723601049864810210.robh@kernel.org>
Date: Thu, 4 Dec 2025 10:13:02 -0600
From: "Rob Herring (Arm)" <robh@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Eric Woudstra <ericwouds@...il.com>,
	Horatiu Vultur <horatiu.vultur@...rochip.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Matthias Brugger <matthias.bgg@...il.com>, netdev@...r.kernel.org,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"David S. Miller" <davem@...emloft.net>,
	Russell King <linux@...linux.org.uk>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Andrew Lunn <andrew@...n.ch>, linux-arm-kernel@...ts.infradead.org,
	Jakub Kicinski <kuba@...nel.org>,
	Marek Behún <kabel@...nel.org>,
	Lee Jones <lee@...nel.org>, linux-phy@...ts.infradead.org,
	Eric Dumazet <edumazet@...gle.com>, devicetree@...r.kernel.org,
	linux-mediatek@...ts.infradead.org, Paolo Abeni <pabeni@...hat.com>,
	Daniel Golle <daniel@...rotopia.org>, linux-kernel@...r.kernel.org,
	Patrice Chotard <patrice.chotard@...s.st.com>,
	Vinod Koul <vkoul@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Subject: Re: [PATCH net-next 3/9] dt-bindings: phy-common-props: RX and TX
 lane polarity inversion


On Sat, 22 Nov 2025 21:33:35 +0200, Vladimir Oltean wrote:
> Differential signaling is a technique for high-speed protocols to be
> more resilient to noise. At the transmit side we have a positive and a
> negative signal which are mirror images of each other. At the receiver,
> if we subtract the negative signal (say of amplitude -A) from the
> positive signal (say +A), we recover the original single-ended signal at
> twice its original amplitude. But any noise, like one coming from EMI
> from outside sources, is supposed to have an almost equal impact upon
> the positive (A + E, E being for "error") and negative signal (-A + E).
> So (A + E) - (-A + E) eliminates this noise, and this is what makes
> differential signaling useful.
> 
> Except that in order to work, there must be strict requirements observed
> during PCB design and layout, like the signal traces needing to have the
> same length and be physically close to each other, and many others.
> 
> Sometimes it is not easy to fulfill all these requirements, a simple
> case to understand is when on chip A's pins, the positive pin is on the
> left and the negative is on the right, but on the chip B's pins (with
> which A tries to communicate), positive is on the right and negative on
> the left. The signals would need to cross, using vias and other ugly
> stuff that affects signal integrity (introduces impedance
> discontinuities which cause reflections, etc).
> 
> So sometimes, board designers intentionally connect differential lanes
> the wrong way, and expect somebody else to invert that signal to recover
> useful data. This is where RX and TX polarity inversion comes in as a
> generic concept that applies to any high-speed serial protocol as long
> as it uses differential signaling.
> 
> I've stopped two attempts to introduce more vendor-specific descriptions
> of this only in the past month:
> https://lore.kernel.org/linux-phy/20251110110536.2596490-1-horatiu.vultur@microchip.com/
> https://lore.kernel.org/netdev/20251028000959.3kiac5kwo5pcl4ft@skbuf/
> 
> and in the kernel we already have merged:
> - "st,px_rx_pol_inv"
> - "st,pcie-tx-pol-inv"
> - "st,sata-tx-pol-inv"
> - "mediatek,pnswap"
> - "airoha,pnswap-rx"
> - "airoha,pnswap-tx"
> 
> and maybe more. So it is pretty general.
> 
> One additional element of complexity is introduced by the fact that for
> some protocols, receivers can automatically detect and correct for an
> inverted lane polarity (example: the PCIe LTSSM does this in the
> Polling.Configuration state; the USB 3.1 Link Layer Test Specification
> says that the detection and correction of the lane polarity inversion in
> SuperSpeed operation shall be enabled in Polling.RxEQ.). Whereas for
> other protocols (SGMII, SATA, 10GBase-R, etc etc), the polarity is all
> manual and there is no detection mechanism mandated by their respective
> standards.
> 
> So why would one even describe rx-polarity and tx-polarity for protocols
> like PCIe, if it had to always be PHY_POL_AUTO?
> 
> Related question: why would we define the polarity as an array per
> protocol? Isn't the physical PCB layout protocol-agnostic, and aren't we
> describing the same physical reality from the lens of different protocols?
> 
> The answer to both questions is because multi-protocol PHYs exist
> (supporting e.g. USB2 and USB3, or SATA and PCIe, or PCIe and Ethernet
> over the same lane), one would need to manually set the polarity for
> SATA/Ethernet, while leaving it at auto for PCIe/USB 3.0+.
> 
> I also investigated from another angle: what if polarity inversion in
> the PHY is one layer, and then the PCIe/USB3 LTSSM polarity detection is
> another layer on top? Then rx-polarity = <PHY_POL_AUTO> doesn't make
> sense, it can still be rx-polarity = <PHY_POL_NORMAL> or <PHY_POL_INVERT>,
> and the link training state machine figures things out on top of that.
> This would radically simplify the design, as the elimination of
> PHY_POL_AUTO inherently means that the need for a property array per
> protocol also goes away.
> 
> I don't know how things are in the general case, but at least in the 10G
> and 28G Lynx SerDes blocks from NXP Layerscape devices, this isn't the
> case, and there's only a single level of RX polarity inversion: in the
> SerDes lane. In the case of PCIe, the controller is in charge of driving
> the RDAT_INV bit autonomously, and it is read-only to software.
> 
> So the existence of this kind of SerDes lane proves the need for
> PHY_POL_AUTO to be a third state.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> ---
>  .../bindings/phy/phy-common-props.yaml        | 45 +++++++++++++++++++
>  include/dt-bindings/phy/phy.h                 |  4 ++
>  2 files changed, 49 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@...nel.org>

Powered by blists - more mailing lists