From: Coia Prant <coiaprant@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jakub Kicinski <kuba@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: pcs: xpcs: make supported_interfaces authoritative
Date: Fri, 30 Oct 2026 21:52:48 +0800 [thread overview]
Message-ID: <A049E9C1-CE52-4B04-8BD4-44962D008F6D@gmail.com> (raw)
In-Reply-To: <20fb8d2d-a20e-472b-8f32-3fe2fec9a425@lunn.ch>
On October 29, 2026 9:20:56 PM GMT+08:00, Andrew Lunn <andrew@lunn.ch> wrote:
>On Thu, Oct 29, 2026 at 06:27:29PM +0800, Coia Prant wrote:
>> pcs.supported_interfaces is the mask of interfaces a given xpcs
>> instance actually supports. The compat table describes what the
>> Synopsys IP can do in general, but a specific integration may support
>> a different subset: the RK3568 XPCS supports 1000BASE-X, SGMII and
>> QSGMII in hardware, but does not implement the C73 10G or 2500BASE-X
>> modes that the Synopsys compat table advertises.
>>
>> The Rockchip glue currently advertises only SGMII, since that is what
>> the RK3568 MAC side supports today. 1000BASE-X and QSGMII can be added
>> later when the MAC side gains support.
>>
>> Without narrowing the mask, stmmac_phylink_setup() merges the PCS
>> supported_interfaces into the MAC mask with phy_interface_or(), so the
>> XPCS would contribute 1000BASE-X, 2500BASE-X, USXGMII and the 10G/25G
>> modes to the combined set. The MAC side forces the phy modes and
>> phylink start passes the mode explicitly, so this does not currently
>> make phylink switch to an unsupported mode, but the combined mask still
>> advertises interfaces the SoC cannot use.
>
>I don't know this code too well, but something does not feel right
>here. It might be due to the way stmmac does PCS with phylink, which
>is often considered broken.
>
>What i would expect to happen is that each piece of hardware indicates
>what it can do, and then phylink finds the common modes.
>
>So maybe stmmac_phylink_setup() is wrong when it ORs them together?
>
>Maybe look at other MAC drivers using pcs and phylink.
>
> Andrew
Hi Andrew,
Thanks for the review. The comment is too terse, let me clarify the
scope of this patch.
The RK3568 XPCS supports 1000BASE-X, SGMII and QSGMII in hardware, but
the Rockchip glue advertises only SGMII for now because that is what
the RK3568 MAC side supports today. 1000BASE-X and QSGMII can be added
later when the MAC side gains support.
On the stmmac side: I agree the phy_interface_or() in
stmmac_phylink_setup() is not the usual intersect model, and it is one
of the reasons stmmac's PCS glue is often considered fragile. But the
DWMAC binding requires phy-mode globally (snps,dwmac.yaml), so the
dwmac-rk glue gets a fixed mode from DT and phylink start passes that
mode explicitly. The OR-merged mask therefore does not currently make
phylink switch to a mode the SoC cannot use.
I've only been touching this area for the last few months, so I'm
guessing it may have been intentional. You might want to ask Russell
King, who designed the original logic, for the rationale.
This patch only touches the PCS side. It makes supported_interfaces
authoritative on the PCS instance, so xpcs_find_compat() does not
configure an interface the glue has marked as unsupported. Reworking
stmmac's OR-merge into a proper intersect model is a separate, larger
topic, and I'd rather not mix it into this fix.
Coia
prev parent reply other threads:[~2026-10-30 13:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 10:27 Coia Prant
2026-10-29 13:10 ` Andrew Lunn
2026-10-29 13:20 ` Andrew Lunn
2026-10-30 13:52 ` Coia Prant [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A049E9C1-CE52-4B04-8BD4-44962D008F6D@gmail.com \
--to=coiaprant@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®