Re: [PATCH net] net: pcs: xpcs-rk: limit advertised interfaces

[Coia Prant <coiaprant@gmail.com>]

On November 3, 2026 10:54:57 AM GMT+08:00, Andrew Lunn <andrew@lunn.ch> wrote:
>> Hi Maxime,
>> 
>> You're right that for modes the PCS does implement, the limit belongs
>> on the MAC side. The complication is that the compat table describes
>> the whole Synopsys IP set, while a given XPCS instance only implements
>> a subset of it. That is a historical design issue in pcs-xpcs: the
>> table mixes C73, C37, 2500BASE-X and 10GBASE-X entries, but different
>> integrations implement different subsets.
>> 
>> On RK3568 the XPCS instance is wired up for the C37 SGMII path only.
>> 1000BASE-X is part of the same C37 core, but I don't have a PHY to test
>> it against. QSGMII is not implemented in this core. 2500BASE-X and
>> 10GBASE-X are separate modes the shared table carries, and neither is
>> implemented on this SoC. C73 is not wired up either.
>> 
>> Trimming the mask is not limiting the PCS, it is cutting the shared
>> table down to what this instance actually implements. A
>> platform-specific glue is the right place to do that.
>
>Are there any registers which describe how the PCS was configured at
>syntheses time?
>
>	Andrew

Hi Andrew,

Yes, looking at the `xpcs_identity` code, the core does probe different
MMDs to get the rough type: PMA/PMD MMD for C73 and VEND2 MMD for C37.

However, even if we determine it's a C37 or C73 block, that only gives
us the rough family, not the exact feature set. For example, a VEND2
(C37) block might not implement 2500BASE-X, and a PMA/PMD (C73) block
might not implement 10GBASE-R. The MMD ID itself doesn't tell us which
of these sub-modes were actually synthesized and wired out.

Since I only have the Rockchip RK3568 PCS documentation, I don't want
to blindly touch the global compat[] table in the core, as it could
easily break other platforms (Intel, NXP, etc.).

That's why intersecting the platform mask with the core mask in the
Rockchip glue is the safest approach for now.

As a bit of context on where this is heading: currently, the PMA layers
for wx, fbnic, and nxp are separate source files but are compiled into
the generic core module, relying on a shared compat table. In a
follow-up net-next series, I plan to split them into actual independent
modules using an abstraction layer and their own xpcs_xxx_create()
functions.

This will allow other platforms (including Rockchip) to do the same
mask intersection and PMA-specific setup without bloating the generic
core with more and more platform quirks. Right now, dwmac-intel seems
to be the only platform that completely relies on the generic core
without a specific PMA module. So keeping the core generic and doing the
narrowing in the glue is a safe, self-contained step that aligns with
that future direction.

Coia