summaryrefslogtreecommitdiff
path: root/include/dt-bindings/phy/phy.h
AgeCommit message (Collapse)Author
2026-01-14Merge tag 'phy_common_properties' into nextVinod Koul
phy common properties Vladimir Oltean <vladimir.oltean@nxp.com> wrote: Introduce "rx-polarity" and "tx-polarity" device tree properties with Kunit tests
2026-01-14dt-bindings: phy-common-props: RX and TX lane polarity inversionVladimir Oltean
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>
2026-01-14dt-bindings: phy: Add PHY_TYPE_XAUI definitionSwapnil Jakhade
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>
2022-08-30dt-bindings: phy: Add PHY_TYPE_USXGMII definitionSwapnil Jakhade
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>
2021-08-07dt-bindings: msm: dsi: document phy-type property for 7nm dsi phyJonathan Marek
Document a new phy-type property which will be used to determine whether the phy should operate in D-PHY or C-PHY mode. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20210617144349.28448-3-jonathan@marek.ca Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-09-18dt-bindings: phy: Add PHY_TYPE_QSGMII definitionSwapnil Jakhade
Add definition for QSGMII phy type. Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1600327846-9733-5-git-send-email-sjakhade@cadence.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-06-29dt-bindings: phy: Add DT bindings for Xilinx ZynqMP PSGTR PHYAnurag Kumar Vulisha
Add DT bindings for the Xilinx ZynqMP PHY. ZynqMP SoCs have a High Speed Processing System Gigabit Transceiver which provides PHY capabilities to USB, SATA, PCIE, Display Port and Ehernet SGMII controllers. Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200629120054.29338-2-laurent.pinchart@ideasonboard.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-05-19dt-bindings: phy: Add PHY_TYPE_XPCS definitionDilip Kota
Add definition for Ethernet PCS phy type. Signed-off-by: Dilip Kota <eswara.kota@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Acked-By: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/6091f0d2a1046f1e3656d9e33b6cc433d5465eaf.1589868358.git.eswara.kota@linux.intel.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-01-17dt-bindings: phy: Add PHY_TYPE_DP definitionJyri Sarha
Add definition for DisplayPort phy type. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 194Thomas Gleixner
Based on 1 normalized pattern(s): license terms gnu general public license gpl version 2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 161 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Steve Winslow <swinslow@gmail.com> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190528170027.447718015@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-23dt-bindings: phy: Add PHY_TYPE_UFS definitionVivek Gautam
Add definition for UFS phy type. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2014-11-26phy: add support for USB cluster on the Armada 375 SoCGregory CLEMENT
The Armada 375 SoC comes with an USB2 host and device controller and an USB3 controller. The USB cluster control register allows to manage common features of both USB controllers. This commit adds a driver integrated in the generic PHY framework to control this USB cluster feature. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [ kishon@ti.com : Made it to use the updated devm_phy_create API and soem cosmentic changes in Kconfig file.] Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Jason Cooper <jason@lakedaemon.net>
2014-11-11phy: Add PHY header file for DT x Driver definesGabriel FERNANDEZ
This provides the shared header file which will be reference from both PHY driver and its associated Device Tree node(s). Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>