From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Coia Prant <coiaprant@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>, Vinod Koul <vkoul@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
Romain Gantois <romain.gantois@bootlin.com>,
Heiner Kallweit <hkallweit1@gmail.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Russell King <linux@armlinux.org.uk>,
Shawn Lin <shawn.lin@rock-chips.com>,
David Heidelberg <david@ixit.cz>,
netdev@vger.kernel.org, linux-rockchip@lists.infradead.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH net-next v3 01/10] net: stmmac: move XPCS lifetime management to platform drivers
Date: Thu, 3 Sep 2026 10:32:34 +0200 [thread overview]
Message-ID: <0dec5462-f6d5-4ef9-9d02-5fdf7f3090a0@bootlin.com> (raw)
In-Reply-To: <20260901150111.141037-2-coiaprant@gmail.com>
Hi again,
On 9/1/26 17:01, Coia Prant wrote:
> The current XPCS creation logic in stmmac_pcs_setup() is problematic
> for several reasons.
>
> First, if a device tree specifies a "pcs-handle" but no select_pcs()
> callback is provided by the platform driver, the created XPCS is never
> used. The phylink framework requires select_pcs() to actually return
> the PCS to the core, so the pcs-handle property becomes effectively
> useless without the matching callback. This is confusing for developers
> who expect that specifying a pcs-handle in their device tree should be
> sufficient to enable the PCS.
>
> Second, and more critically, when stmmac_pcs_setup() fails to create
> an XPCS (either because no pcs-handle is present and no pcs_mask is
> configured), it falls through to the else branch and leaves
> priv->hw->xpcs as NULL. This will silently override any XPCS that a
> platform driver may have already set up during its own initialization,
> for example in a pcs_init() callback or during probe. The platform
> driver has no way to prevent this override because the common code
> runs unconditionally after the platform-specific initialization.
>
> After commit 93f84152e4ae ("net: stmmac: clean up
> stmmac_mac_select_pcs()"), the common code no longer falls back to
> priv->hw->phylink_pcs if select_pcs() is not set. This change
> reinforces that each platform must manage its own PCS life cycle
> explicitly, but the XPCS creation code in stmmac_pcs_setup() was not
> updated to match this new expectation, leaving a gap where platform
> drivers have no clean way to take control of XPCS creation.
>
> Address all of these issues by introducing pcs_init() and pcs_exit()
> callbacks in plat_stmmacenet_data. These callbacks give platform
> drivers full control over when and how the XPCS is created, configured,
> and destroyed. The common stmmac_pcs_setup() and stmmac_pcs_clean()
> functions are simplified to just call these callbacks, removing the
> confusing and error-prone XPCS creation logic from the common code.
>
> Platforms that do not need an XPCS simply leave the callbacks as NULL
> and no change in behavior occurs. Platforms that do need an XPCS can
> now create it with the exact configuration they require, including
> wrapping it with custom phylink_pcs_ops when necessary.
>
> Existing platform drivers (intel, rzn1, socfpga) are updated to use
> the new callbacks by moving their XPCS creation and cleanup logic into
> pcs_init() and pcs_exit(). In their pcs_exit() implementations, the
> pointer to the destroyed PCS is explicitly set to NULL to avoid
> dangling pointer references.
>
> Signed-off-by: Coia Prant <coiaprant@gmail.com>
> ---
> .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 44 +++++++++++++++++--
> .../stmicro/stmmac/dwmac-renesas-gbeth.c | 7 ++-
> .../net/ethernet/stmicro/stmmac/dwmac-rzn1.c | 7 ++-
> .../ethernet/stmicro/stmmac/dwmac-socfpga.c | 7 ++-
> .../net/ethernet/stmicro/stmmac/stmmac_mdio.c | 37 +++-------------
> 5 files changed, 61 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> index f5f9fa67ecd77..fd5f01c8941c1 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> @@ -603,13 +603,47 @@ static void common_default_data(struct plat_stmmacenet_data *plat)
> plat->mdio_bus_data->needs_reset = true;
> }
>
> +static int intel_mgbe_pcs_init(struct stmmac_priv *priv)
> +{
> + struct fwnode_handle *devnode, *pcsnode;
> + struct dw_xpcs *xpcs = NULL;
> + int addr;
> +
> + devnode = dev_fwnode(priv->device);
> +
> + if (fwnode_property_present(devnode, "pcs-handle")) {
> + pcsnode = fwnode_find_reference(devnode, "pcs-handle", 0);
> + xpcs = xpcs_create_fwnode(pcsnode);
> + fwnode_handle_put(pcsnode);
> + } else {
> + addr = ffs(priv->plat->mdio_bus_data->pcs_mask) - 1;
> + xpcs = xpcs_create_mdiodev(priv->mii, addr);
> + }
Sorry I had a second look at that after a good night's sleep, and actually here
we may regress. The original logic checked for "pcs-handle" presence, then
for the pcs mask, but if no PCS is found we didn't error out, we returned 0.
This is making it mandatory to have a PCS. Please handle gracefully the "there's no
PCS" case :(
Maxime
next prev parent reply other threads:[~2026-09-03 8:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 15:01 [PATCH net-next v3 00/10] net: pcs: add basic support for RK3568 XPCS Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 01/10] net: stmmac: move XPCS lifetime management to platform drivers Coia Prant
2026-09-02 22:23 ` Maxime Chevallier
2026-09-03 8:32 ` Maxime Chevallier [this message]
2026-09-03 8:51 ` Coia Prant
2026-09-03 8:58 ` Maxime Chevallier
2026-09-01 15:01 ` [PATCH net-next v3 02/10] dt-bindings: phy: rockchip: naneng-combphy: add rockchip,sgmii-mac-sel property Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 03/10] phy: rockchip: naneng-combphy: add SGMII MAC selection for RK3568 Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 04/10] dt-bindings: net: pcs: add rockchip,rk3568-xpcs support Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 06/10] net: pcs: xpcs: add ANRESTART support for SGMII link recovery Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 07/10] net: pcs: xpcs: add Rockchip RK3568 platform glue driver Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 08/10] net: stmmac: dwmac-rk: add SGMII support for RK3568 Coia Prant
2026-09-03 8:34 ` Maxime Chevallier
2026-09-03 8:38 ` Coia Prant
2026-09-03 8:44 ` Maxime Chevallier
2026-09-03 8:59 ` Maxime Chevallier
2026-09-01 15:01 ` [PATCH net-next v3 09/10] arm64: dts: rockchip: rk3568-photonicat: enable SGMII LAN port Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 10/10] MAINTAINERS: add entry for Rockchip XPCS driver Coia Prant
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=0dec5462-f6d5-4ef9-9d02-5fdf7f3090a0@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=coiaprant@gmail.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=david@ixit.cz \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=heiko@sntech.de \
--cc=hkallweit1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
--cc=neil.armstrong@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh@kernel.org \
--cc=romain.gantois@bootlin.com \
--cc=shawn.lin@rock-chips.com \
--cc=vkoul@kernel.org \
/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