[PATCH RFC v3 04/12] net: pcs: add NXP SerDes XPCS shared core

Jan Petrous jan.petrous at oss.nxp.com
Sat Oct 10 23:03:27 PDT 2026


On Sun, Sep 20, 2026 at 08:39:26PM +0200, Andrew Lunn wrote:
> On Sat, Sep 19, 2026 at 08:54:32AM +0200, Jan Petrous via B4 Relay wrote:
> > From: Clark Wang <xiaoning.wang at nxp.com>
> > 
> > The SerDes subsystems found on NXP S32G and i.MX SoCs integrate a
> > Synopsys DesignWare Ethernet XPCS and an Ethernet PHY (PMA) with an
> > identical register layout. Only the register transport differs: indirect
> > memory mapped access on S32G, Clause 45 MDIO on i.MX.
> > 
> > Add a transport agnostic phylink PCS core which operates on regmaps
> > provided by the platform glue.
> 
> What is not transport agnostic with the current code.
> 
> Think carefully about that, before you answer.
> 

Ok, got it, pcs-xpcs only reaches the hardware through mdiodev_c45_*(), so
whatever sits behind the mii_bus is the transport. pcs-xpcs-plat already
puts the DW indirect MMIO viewport behind one, sja1105 and txgbe put
their own register access behind one, and on i.MX the XPCS is on plain
Clause 45 MDIO in the first place. The claim in the commit message was
wrong, and with it the justification for a second core.

For the next version I will drop this patch and move S32G onto
pcs-xpcs. The SerDes PHY driver registers a mii_bus per XPCS instance
over the existing indirect accessor and creates the PCS with
xpcs_create_pcs_mdiodev(). The S32G PMA sequence becomes a
dw_xpcs_compat .pma_config keyed on an S32G PMA ID, the same way the
SJA1110 and TXGBE ones are.

That leaves two things S32G needs from pcs-xpcs, neither of which is
about the transport:

 - skipping the generic soft reset. The vendor reset
   (VR_MII_DIG_CTRL1.VR_RST) is part of an ordered bring-up of both
   XPCS instances, which the SerDes PHY driver owns because the PMA is
   shared with the PCIe lane. The PMA ID check that already clears
   need_reset for TXGBE and FBNIC would cover it.

 - no EEE. S32G3 does not implement VR_MII_EEE_MCTRL0/1, so
   pcs_enable_eee/pcs_disable_eee must not touch them.

Both will be separate small patches against pcs-xpcs so they can be
judged on their own.

Thanks,
Jan



More information about the linux-phy mailing list