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

[Jan Petrous]

On Mon, Oct 12, 2026 at 01:57:13PM -0500, Frank Li wrote:
> 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 ...>;
> }
> 

The MAC needs a phylink_pcs, not a PHY: the XPCS does the C37 autoneg
and link state. pcs-handle is the standard property for that, and in
v4 the XPCS is driven by pcs-xpcs. The lane mux is fixed before the
SerDes reset is released, so the MAC has nothing to set on a generic
PHY, and a "pcs-to-phy" node would describe a block the SoC does not
have.

> >
> > 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)>;
> 

Rob suggested that in v2 [1]. Child nodes stayed because:

- SUBSYS_MODE is written before the reset is released, so the SerDes
  driver needs the whole lane mux at its own probe. With cells it would
  have to walk the tree for its consumers, including disabled ones, and
  an unconnected lane has no consumer to carry a cell.

- The MAC uses pcs-handle, which has no argument cells, so the XPCS
  instance has nowhere else to go.

- A type cell duplicates phy_set_mode_ext(PHY_MODE_PCIE) from the PCIe
  driver.

- In mode 0 there is one x2 PHY, not two lane PHYs.

I will put this in the v4 commit message. If you or Rob still prefer
cells, let me know.

[1] https://lore.kernel.org/all/CAL_Jsq+SswpTjQShfkdhVwL_k8gJ_5+NrecPCUiFR52UB5zNMA@mail.gmail.com/

BR.
/Jan