linux-toradex.git/include/dt-bindings/phy, branch master Linux kernel for Apalis and Colibri modules Merge tag 'phy_common_properties' into next 2026-01-14T13:22:57+00:00 Vinod Koul vkoul@kernel.org 2026-01-14T13:22:57+00:00 a699808928937000e550a7cd5355db93ef99e236 phy common properties Vladimir Oltean <vladimir.oltean@nxp.com> wrote: Introduce "rx-polarity" and "tx-polarity" device tree properties with Kunit tests 
phy common properties

Vladimir Oltean <vladimir.oltean@nxp.com> wrote:

Introduce "rx-polarity" and "tx-polarity" device tree properties with
Kunit tests
dt-bindings: phy-common-props: RX and TX lane polarity inversion 2026-01-14T12:46:05+00:00 Vladimir Oltean vladimir.oltean@nxp.com 2026-01-11T09:39:33+00:00 fceb17ac05e772ffc82f1f008e876bf7752f0576 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@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-5-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
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@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260111093940.975359-5-vladimir.oltean@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dt-bindings: phy: Add PHY_TYPE_XAUI definition 2026-01-14T09:33:09+00:00 Swapnil Jakhade sjakhade@cadence.com 2026-01-12T05:46:30+00:00 a632a2a0db8b4d24076a03889efa25c6058d0746 XAUI (eXtended Attachment Unit Interface) is a high-speed serial interface standard for 10 Gigabit Ethernet (10GbE). It uses four lanes with each lane operating at 3.125 Gbps (totaling 10 Gbps), to extend the XGMII interface across circuit boards, commonly used in backplanes for networking switches and high-performance computing. XAUI is defined as a standardized instantiation of XGMII Extender in the IEEE 802.3 specification. Add definition for XAUI PHY type. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> [s-vadapalli: added detailed description of XAUI in the commit message] Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260112054636.108027-2-s-vadapalli@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
XAUI (eXtended Attachment Unit Interface) is a high-speed serial interface
standard for 10 Gigabit Ethernet (10GbE). It uses four lanes with each
lane operating at 3.125 Gbps (totaling 10 Gbps), to extend the XGMII
interface across circuit boards, commonly used in backplanes for
networking switches and high-performance computing. XAUI is defined as a
standardized instantiation of XGMII Extender in the IEEE 802.3
specification.

Add definition for XAUI PHY type.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
[s-vadapalli: added detailed description of XAUI in the commit message]
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260112054636.108027-2-s-vadapalli@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: document PHY AUX clock on SM8[456]50 SoCs 2024-04-05T17:04:00+00:00 Neil Armstrong neil.armstrong@linaro.org 2024-03-22T09:42:38+00:00 72bea132f3680ee51e7ed2cee62892b6f5121909 The PCIe Gen4x2 PHY found in the SM8[456]50 SoCs have a second clock named "PHY_AUX_CLK" which is an input of the Global Clock Controller (GCC) which is muxed & gated then returned to the PHY as an input. Document the clock IDs to select the PIPE clock or the AUX clock, also enforce a second clock-output-names and a #clock-cells value of 1 for the PCIe Gen4x2 PHY found in the SM8[456]50 SoCs. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240322-topic-sm8x50-upstream-pcie-1-phy-aux-clk-v2-1-3ec0a966d52f@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org> 
The PCIe Gen4x2 PHY found in the SM8[456]50 SoCs have a second clock named
"PHY_AUX_CLK" which is an input of the Global Clock Controller (GCC) which
is muxed & gated then returned to the PHY as an input.

Document the clock IDs to select the PIPE clock or the AUX clock,
also enforce a second clock-output-names and a #clock-cells value of 1
for the PCIe Gen4x2 PHY found in the SM8[456]50 SoCs.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240322-topic-sm8x50-upstream-pcie-1-phy-aux-clk-v2-1-3ec0a966d52f@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dt-bindings: phy: qcom,qmp-usb3-dp: fix sc8280xp binding 2022-11-24T17:21:50+00:00 Johan Hovold johan+linaro@kernel.org 2022-11-21T08:50:45+00:00 e1c4c5436b4ad579762fbe78bfabc8aef59bd5b1 The current QMP USB3-DP PHY bindings are based on the original MSM8996 binding which provided multiple PHYs per IP block and these in turn were described by child nodes. The QMP USB3-DP PHY block provides a single multi-protocol PHY and even if some resources are only used by either the USB or DP part of the device there is no real benefit in describing these resources in child nodes. The original MSM8996 binding also ended up describing the individual register blocks as belonging to either the wrapper node or the PHY child nodes. This is an unnecessary level of detail which has lead to problems when later IP blocks using different register layouts have been forced to fit the original mould rather than updating the binding. The bindings are arguable also incomplete as they only the describe register blocks used by the current Linux drivers (e.g. does not include the PCS LANE registers). This is specifically true for later USB4-USB3-DP QMP PHYs where the TX registers are used by both the USB3 and DP parts of the PHY (and where the USB4 part of the PHY was not covered by the binding at all). Notably there are also no DP "RX" (sic) registers as described by the current bindings and the DP "PCS" region is really a set of DP_PHY registers. Add a new binding for the USB4-USB3-DP QMP PHYs found on SC8280XP which further bindings can be based on. Note that the binding uses a PHY index to access either the USB3 or DP part of the PHY and that this can later be used also for the USB4 part if needed. Similarly, the clock inputs and outputs can later be extended to support USB4. Also note that the current binding is simply removed instead of being deprecated as it was only recently merged and would not allow for supporting DP mode. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20221121085058.31213-3-johan+linaro@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org> 
The current QMP USB3-DP PHY bindings are based on the original MSM8996
binding which provided multiple PHYs per IP block and these in turn were
described by child nodes.

The QMP USB3-DP PHY block provides a single multi-protocol PHY and even
if some resources are only used by either the USB or DP part of the
device there is no real benefit in describing these resources in child
nodes.

The original MSM8996 binding also ended up describing the individual
register blocks as belonging to either the wrapper node or the PHY child
nodes.

This is an unnecessary level of detail which has lead to problems when
later IP blocks using different register layouts have been forced to fit
the original mould rather than updating the binding. The bindings are
arguable also incomplete as they only the describe register blocks used
by the current Linux drivers (e.g. does not include the PCS LANE
registers).

This is specifically true for later USB4-USB3-DP QMP PHYs where the TX
registers are used by both the USB3 and DP parts of the PHY (and where
the USB4 part of the PHY was not covered by the binding at all). Notably
there are also no DP "RX" (sic) registers as described by the current
bindings and the DP "PCS" region is really a set of DP_PHY registers.

Add a new binding for the USB4-USB3-DP QMP PHYs found on SC8280XP which
further bindings can be based on.

Note that the binding uses a PHY index to access either the USB3 or DP
part of the PHY and that this can later be used also for the USB4 part
if needed.

Similarly, the clock inputs and outputs can later be extended to support
USB4.

Also note that the current binding is simply removed instead of being
deprecated as it was only recently merged and would not allow for
supporting DP mode.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20221121085058.31213-3-johan+linaro@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dt-bindings: phy: Add PHY_TYPE_USXGMII definition 2022-08-30T05:12:57+00:00 Swapnil Jakhade sjakhade@cadence.com 2022-06-28T12:22:50+00:00 288440de9e5fdb4a3ff73864850f080c1250fc81 Add definition for USXGMII phy type. Cc: Rob Herring <robh@kernel.org> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220628122255.24265-3-rogerq@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Add definition for USXGMII phy type.

Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220628122255.24265-3-rogerq@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dt-bindings: phy: cadence-sierra: Add clock ID for derived reference clock 2021-12-27T11:05:09+00:00 Swapnil Jakhade sjakhade@cadence.com 2021-12-23T06:01:36+00:00 637feefb8ac53fbe1147edb707b03dc09839fdf5 Add clock ID for Sierra derived reference clock. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211223060137.9252-15-sjakhade@cadence.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Add clock ID for Sierra derived reference clock.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211223060137.9252-15-sjakhade@cadence.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dt-bindings: phy: cadence-torrent: Rename SSC macros to use generic names 2021-12-27T11:05:08+00:00 Swapnil Jakhade sjakhade@cadence.com 2021-12-23T06:01:25+00:00 253f06c7b1c1729b50e7ec52638e046239327bb1 Rename SSC macros to use generic names instead of PHY specific names, so that they can be used to specify SSC modes for both Torrent and Sierra. Renaming the macros should not affect the things as these are not being used in any DTS file yet. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211223060137.9252-4-sjakhade@cadence.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Rename SSC macros to use generic names instead of PHY specific names,
so that they can be used to specify SSC modes for both Torrent and
Sierra. Renaming the macros should not affect the things as these are
not being used in any DTS file yet.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211223060137.9252-4-sjakhade@cadence.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dt-bindings: phy: phy-imx8-pcie: Add binding for the pad modes of imx8 pcie phy 2021-12-14T14:32:32+00:00 Richard Zhu hongxing.zhu@nxp.com 2021-12-02T08:02:31+00:00 f6f787874aa52bbfbfd0210f519439d38fd5377f Add binding for reference clock PAD modes of the i.MX8 PCIe PHY. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Tim Harvey <tharvey@gateworks.com> Tested-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1638432158-4119-2-git-send-email-hongxing.zhu@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Add binding for reference clock PAD modes of the i.MX8 PCIe PHY.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Tim Harvey <tharvey@gateworks.com>
Tested-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1638432158-4119-2-git-send-email-hongxing.zhu@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dt-bindings: phy: Add constants for lan966x serdes 2021-11-23T07:39:08+00:00 Horatiu Vultur horatiu.vultur@microchip.com 2021-11-16T10:08:17+00:00 ea8a163e02d6925773129e2dd86e419e491b791d Lan966x has: 2 integrated PHYs, 3 SerDes and 2 RGMII interfaces. Which requires to be muxed based on the HW representation. So add constants for each interface to be able to distinguish them. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20211116100818.1615762-3-horatiu.vultur@microchip.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Lan966x has: 2 integrated PHYs, 3 SerDes and 2 RGMII interfaces. Which
requires to be muxed based on the HW representation.

So add constants for each interface to be able to distinguish them.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Link: https://lore.kernel.org/r/20211116100818.1615762-3-horatiu.vultur@microchip.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>