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

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

[Coia Prant]

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.

Signed-off-by: Coia Prant <coiaprant@gmail.com>
---
 drivers/net/pcs/pcs-xpcs-rk.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/pcs/pcs-xpcs-rk.c b/drivers/net/pcs/pcs-xpcs-rk.c
index 6f0a110e32d2..cc11a70d624f 100644
--- a/drivers/net/pcs/pcs-xpcs-rk.c
+++ b/drivers/net/pcs/pcs-xpcs-rk.c
@@ -536,6 +536,12 @@ struct dw_xpcs *xpcs_rk_create(struct device *dev, struct device_node *pcs, int
 		return xpcs;
 	}
 
+	/*
+	 * The RK3568 XPCS supports 1000BASE-X, SGMII and QSGMII.
+	 */
+	phy_interface_zero(xpcs->pcs.supported_interfaces);
+	__set_bit(PHY_INTERFACE_MODE_SGMII, xpcs->pcs.supported_interfaces);
+
 	xpcs_config_eee_mult_fact(xpcs, pxpcs->eee_mult_fact);
 	put_device(&pdev->dev);
 	return xpcs;
-- 
2.47.3

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

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

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

[Coia Prant]

<netdev-bot+sinfo@kernel.org> 于2026年10月29日周四 17:56写道：
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Hi,

Thanks for the check. Replying with the missing information and a
respin that folds a related core fix into the same patch.

How the issue was discovered: this is a known gap previously flagged by
Sashiko review. xpcs_find_compat() only walks desc->compat[] and never
looks at pcs.supported_interfaces, so the mask the glue sets is written
but never consulted by the core. The same review pointed out that the
generic xpcs core fills pcs.supported_interfaces from the compat table,
which for the Synopsys ID includes 1000BASE-X, 2500BASE-X, USXGMII and
the 10G/25G modes. The RK3568 XPCS supports 1000BASE-X, SGMII and
QSGMII in hardware, but does not implement the C73 10G or 2500BASE-X
modes, and the RK3568 MAC side currently only supports SGMII.

The respin fixes both sides in one patch: the glue narrows the mask to
SGMII, and the core respects it in xpcs_find_compat().

Whether it was actually triggered: no, this is theoretical. The
affected Rockchip platform is not present in any released kernel, and
the MAC side forces the phy mode, so phylink start passes the mode
explicitly and does not normally pass an interface outside the mask.
The patch makes the mask the single source of truth for both the core
and the glue.

pw-bot: cr

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

[Maxime Chevallier]

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

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

[Coia Prant]

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

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

[Andrew Lunn]

> 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

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

[Coia Prant]

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