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

[Jan Petrous]

On Tue, Oct 13, 2026 at 03:47:58AM +0800, Coia Prant wrote:
> Hi Jan,
> 
> Thanks for the pointers. A few thoughts.
> 
> > Yes. The S32G accessor is the same DW indirect scheme pcs-xpcs-plat
> > implements (page into the viewport at 0xff, then the low address byte
> > at a 4-byte stride), so there is no reason for S32G to carry its own
> > copy of the XPCS code. The next version drops the shared core, exposes
> > each XPCS instance as a mii_bus from the SerDes PHY driver and creates
> > the PCS with xpcs_create_pcs_mdiodev(), much like the RK3568 glue.
> > Details in my reply to Andrew.
> >
> > The part that does not fit pcs-xpcs-plat as-is is ownership, not
> > access: the XPCS windows sit inside the SerDes subsystem register
> > space, and their bring-up is ordered against the PCIe lane and the
> > other XPCS instance, so the bus is registered by the SerDes PHY driver
> > rather than by a standalone snps,dw-xpcs device. The accessor itself
> > is a few lines; if Alex's pcs-xpcs-regmap is merged first I will use
> > it rather than open-code another bus.
> 
> On the transport split: I think the cleanest path is to split the MMIO
> accessor out into its own module, say pcs-xpcs-mmio, exporting the
> read/write helpers. Then pcs-xpcs-plat can call into those exported

Fine with me. The S32G accessor is a few lines, so I will move it onto
pcs-xpcs-regmap if that lands first, or onto a shared mmio helper if
you post one. Until then it stays open-coded in the glue.

> symbols instead of open-coding the page/stride scheme, and S32G can do
> the same for its indirect window. That way nobody carries a private
> copy of the accessor. If that turns out to be too invasive for plat,
> keeping a separate pcs-xpcs-plat copy is workable too, but I'd rather
> avoid it.
> 
> If Alex's pcs-xpcs-regmap lands first, that's the natural place for
> the S32G accessor; pcs-xpcs-mmio would only be needed if the regmap
> approach doesn't fit.
> 
> > S32G needs the same kind of thing: skip the generic soft reset, and no
> > EEE registers. I will start with the existing PMA-ID mechanism, since
> > that is what TXGBE and FBNIC use today, and switch to a callback if one
> > is agreed in the Rockchip thread. I'll Cc you on those patches.
> 
> On the shared-core duplication: rather than copying the whole XPCS
> core, I'd look at how the existing users express their quirks.
> 
> Wangxun has a genuinely different PMA ID, so it can branch on the
> ID before the reset path and keep the generic core untouched.
> 
> The older NXP devices do the opposite: they fake the PCS ID at the MDIO
> layer so the core sees a magic value it then interprets. That leaves
> the magic in the core and a fake ID in the glue, and it doesn't scale
> to a third user.
> 
> For S32G, I'd prefer one of these two approaches:
> 
> - A flag in struct dw_xpcs, e.g. DW_XPCS_NO_RESET, that the glue sets
>   and the core checks before the soft reset and EEE paths. Works when
>   the quirk applies to a whole instance regardless of the PMA ID.
> - A platform callback, e.g. plat->pma_config(), where the glue can
>   return early to skip the parts it doesn't need. More flexible, but
>   also more surface area; I'd only go there if flags aren't enough.
> 
> Either is better than another fake ID, because the quirk stays visible
> at the point where it matters instead of being hidden behind a made-up
> value in the transport layer.
> 

Agreed on the principle. The problem is that pcs_pre_config and the
PMA hook are reached only through the ID-keyed compat table, and S32G
needs a pma_config (link timer, lane on MPLLA). Without a platform
callback the ID is the only way in.

What I have for v4 is an ID-keyed entry with the two quirks as
explicit flags in struct dw_xpcs_desc (no soft reset, no EEE), so at
least the table says what the entry does.

> One question: how does S32G relate to the earlier NXP devices already
> in pcs-xpcs.c? Same IP, same PCS ID, same quirks, or something else?
> If they're the same family, it would be good to clean all of them up
> in one go rather than adding a third mechanism on top of the old
> fake-ID one.
> 

Same DW XPCS IP, different integration. SJA1105/1110 are switches with
the XPCS behind their internal MDIO; S32G is an SoC with the XPCS in an
MMIO window inside the SerDes, sharing the PMA with a PCIe lane. The
PMA sequences differ, and so do the quirks. The ID is synthetic in all
three cases. On S32G the XPCS reports the generic DW ID 0x7996ced0
and the PMA/PCS/AN MMDs read as zero (checked on an RDB3), so there is
no hardware ID to key S32G behaviour on.

> Separately, I have a plan to propose platform callbacks for the XPCS core
> at some point, regardless of whether S32G ends up needing them. The
> core currently has no way for a platform glue or PMA to limit or override
> parts of the generic behaviour, and I think that gap needs closing.
> The exact shape can be discussed once RK3568 lands. Happy to Cc you on
> the related thread when that happens.
> 

Yes, please Cc me on the callback thread.

BR.
/Jan