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

[Frank Li]

On Tue, Oct 13, 2026 at 04:40:46PM +0200, Jan Petrous wrote:
> 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@xxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > From: "Jan Petrous (OSS)" <jan.petrous@xxxxxxxxxxx>
> > >
> > > 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@xxxxxxxxxx>
> > > Signed-off-by: Vincent Guittot <vincent.guittot@xxxxxxxxxx>
> > > Signed-off-by: Jan Petrous (OSS) <jan.petrous@xxxxxxxxxxx>
> > > ---
> > >  .../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@xxxxxxx>
> > > +  - Jan Petrous <jan.petrous@xxxxxxxxxxx>
> > > +
> > > +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.

I think Rob suggestion is better.  ethernet controller should support
standard phy interface, more devices will share phy between PCI and
ethernet.

Frank

>
> [1] https://lore.kernel.org/all/CAL_Jsq+SswpTjQShfkdhVwL_k8gJ_5+NrecPCUiFR52UB5zNMA@xxxxxxxxxxxxxx/
>
> BR.
> /Jan
>