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

[Coia Prant <coiaprant@gmail.com>]

On October 31, 2026 4:44:22 AM GMT+08:00, Maxime Chevallier <maxime.chevallier@bootlin.com> wrote:
>Hi Coia,
>
>On 10/29/26 10:49, Coia Prant wrote:
>> The RK3568 XPCS supports 1000BASE-X, SGMII and QSGMII, but the RK3568
>> GMAC only implements SGMII, so only SGMII is advertised in
>> supported_interfaces.
>> 
>> The generic xpcs core fills the mask from the compat table, which
>> includes 1000BASE-X, QSGMII and the higher-speed modes. Clearing it and
>> setting only SGMII keeps phylink from validating interfaces that are
>> not usable here.
>> 
>> 1000BASE-X and QSGMII can be enabled later when a board actually wires
>> them up.
>
>So the PCS supports them, but not the MAC ? The correct fix for that is
>likely in the MAC then.
>
>There's nothing board-specific when it comes to supporting 1000BaseX if you
>already support SGMII, 2500BaseX may work (it's 1000BaseX but 2.5x faster).
>
>Ii may just be that these modes aren't implemented in the MAC, so we should
>keep them enabled at the PCS level.
>
>Maxime
>

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.

For 2500BASE-X there is also a physical conflict: it runs at 3.125
Gbps on the SerDes while SGMII runs at 1.25 Gbps, so the same lane
cannot do both.

So the mask does two things: it trims the entries this instance does
not implement, and it leaves out 1000BASE-X because it is untested
today. If you'd prefer I keep 1000BASE-X in the mask and only trim the
unimplemented entries, I can do that.

The xpcs_find_compat() part is the more general fix: it makes the mask
authoritative so the core does not configure an interface the glue has
marked unsupported.

I agree the stmmac OR-merge is the architectural issue, but I'd rather
not mix that into this fix. The compat table mixing is a separate
discussion too, but I'm happy to follow up on it if you think it is
worth pursuing.

This reply is to the v1 thread; v2 with the folded xpcs_find_compat()
change is already on the list, please have a look there.

Coia