[PATCH RFC v3 01/12] dt-bindings: phy: Add NXP S32G SerDes subsystem

[Frank Li]

On Sat, Sep 19, 2026 at 08:54:29AM +0200, Jan Petrous via B4 Relay wrote:
> [You don't often get email from devnull+jan.petrous.oss.nxp.com at kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: "Jan Petrous (OSS)" <jan.petrous at oss.nxp.com>
>
> The S32G SerDes subsystem multiplexes two lanes between a PCIe PHY and
> two DesignWare XPCS instances. Describe it with one node per SerDes and
> one child node per lane.
>
> Compared to the previous revision, the vendor nxp,sys-mode property is
> removed: the SS_RW_REG_0[SUBSYS_MODE] value is fully derivable from the
> child-node lane mux and the XPCS instance routing (nxp,xpcs-instance).
> Each working mode described here has a unique lane mux, so the mode is
> a pure function of the child nodes. The reference-clock rate is
> validated against the derived mode; it is not used to select it.
>
> The 3.125 Gbit/s working modes are deliberately not described yet.
> Distinguishing them from the 1.25 Gbit/s dual-XPCS mode requires a
> per-lane 2500BASE-X capability that this binding does not express, and
> the reference clock does not distinguish them either - both accept 100
> or 125 MHz. They are added by the 2500BASE-X follow-up.
>
> Only the PCIe lane child gets '#phy-cells'. An XPCS lane is not a
> generic PHY provider; the Ethernet controller references it through the
> standard pcs-handle property instead.

Is it possible Ether controller use standard phy interface? of use standard
pcs-handle to phy convertion

pcs-handle = <&pcs>

pcs: pcs = {
	compatible = "pcs-to-phy";
	phys = <&phy ...>;
}

>
> S32G2 and S32G3 use distinct compatibles without fallback because the
> full reference-manual mode tables differ per SoC and per SerDes
> instance.
>
> Co-developed-by: Vincent Guittot <vincent.guittot at linaro.org>
> Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> Signed-off-by: Jan Petrous (OSS) <jan.petrous at oss.nxp.com>
> ---
>  .../devicetree/bindings/phy/nxp,s32g-serdes.yaml   | 258 +++++++++++++++++++++
>  1 file changed, 258 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> new file mode 100644
> index 000000000000..6343d01bfde4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> @@ -0,0 +1,258 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/nxp,s32g-serdes.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP S32G2xxx/S32G3xxx SerDes PHY subsystem
> +
> +maintainers:
> +  - Ghennadi Procopciuc <ghennadi.procopciuc at nxp.com>
> +  - Jan Petrous <jan.petrous at oss.nxp.com>
> +
> +description: |
> +  The SerDes subsystem multiplexes two SerDes lanes between one PCIe
> +  controller PHY and two Synopsys DesignWare XPCS (Ethernet PCS) instances,
> +  behind a shared 2-lane combo PHY. The active routing is selected by the
> +  SS_RW_REG_0[SUBSYS_MODE] field.
> +
> +  Reference-manual working modes described by this binding:
> +
> +  Mode  Lane0   Lane1   PHY refclk (MHz)  Description
> +  ------------------------------------------------------------
> +  0     PCIe    PCIe    100               PCIe x2
> +  1     PCIe    XPCS0   100               PCIe x1 + SGMII
> +  2     PCIe    XPCS1   100               PCIe x1 + SGMII
> +  3     XPCS0   XPCS1   100 or 125        dual SGMII, 1.25 Gbit/s
> +
> +  Which Ethernet MAC an XPCS instance feeds is fixed by the SoC integration
> +  and differs per SoC and per SerDes instance - on S32G3 SerDes_0, XPCS0
> +  feeds GMAC0 and XPCS1 feeds PFE_MAC2, while on SerDes_1 the same two
> +  instances feed PFE_MAC0 and PFE_MAC1. That mapping is a property of the
> +  SoC, not of this binding, and is resolved by the driver.

Roughly look like use argument is little bit better

<&phys PHY_MODE instance(0/1)>;

Frank