From: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
To: Maxime Chevallier <maxime.chevallier@bootlin.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>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <Jose.Abreu@synopsys.com>
Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net] net: stmmac: hold runtime PM reference in setup_tc
Date: Thu, 27 Aug 2026 09:11:55 +0200 [thread overview]
Message-ID: <ao_jO442V4eG7xd0@lore-desk> (raw)
In-Reply-To: <20260824-stmmac-setup-tc-enable-pm-v1-1-45172d241a4b@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 5230 bytes --]
> The qdisc offload callbacks invoked by stmmac_setup_tc() program
> MTL/MAC registers, but they can be reached while the interface is down,
> when stmmac_release() has dropped the runtime PM usage counter and the
> device may be suspended with its clocks gated. Accessing the registers
> in that state can trigger a bus error.
>
> Hold a runtime PM reference while configuring the register-touching
> qdisc offloads (mqprio, cbs and taprio) so the device is active, and its
> clocks enabled, whenever the MTL/MAC registers are programmed.
>
> The TC block callback stmmac_setup_tc_block_cb() programs the MTL/MAC
> registers as well, but it runs asynchronously from stmmac_setup_tc(),
> outside the runtime PM reference held there. Hold a runtime PM reference
> for the whole stmmac_setup_tc_block_cb() call as well, covering the
> cls_u32/cls_flower setup and the queue enable/disable accesses.
>
> No reference is held for the TC_SETUP_BLOCK bookkeeping itself, the
> TC_QUERY_CAPS query or the tc-etf path, since none of them touch the
> registers synchronously. In particular the block bind/unbind must reach
> flow_block_cb_setup_simple() even when the device is suspended, so the
> driver never leaves a stale flow_block_cb on its block list.
>
> Fixes: 1f705bc61aee ("net: stmmac: Add support for CBS QDISC")
> Fixes: 4dbbe8dde848 ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser")
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 34 ++++++++++++++++++++---
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index b2b7d0242dd3..4baf40fb01dc 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -6392,9 +6392,13 @@ static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
> void *cb_priv)
> {
> struct stmmac_priv *priv = cb_priv;
> - int ret = -EOPNOTSUPP;
> + int ret;
>
> if (!tc_cls_can_offload_and_chain0(priv->dev, type_data))
> + return -EOPNOTSUPP;
> +
> + ret = pm_runtime_resume_and_get(priv->device);
> + if (ret < 0)
> return ret;
>
> __stmmac_disable_all_queues(priv);
> @@ -6411,6 +6415,8 @@ static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
> }
>
> stmmac_enable_all_queues(priv);
> + pm_runtime_put(priv->device);
commenting on sashiko's report:
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824-stmmac-setup-tc-enable-pm-v1-1-45172d241a4b%40oss.qualcomm.com
- Dropping the -EOPNOTSUPP initializer of ret changes what this callback
returns for tc_setup_type values the driver does not handle. ret is now
first assigned by pm_runtime_resume_and_get(), which returns exactly 0 on
success
- I will fix it in v2
> +
> return ret;
> }
>
> @@ -6420,26 +6426,46 @@ static int stmmac_setup_tc(struct net_device *ndev, enum tc_setup_type type,
> void *type_data)
> {
> struct stmmac_priv *priv = netdev_priv(ndev);
> + int ret;
>
> switch (type) {
> case TC_QUERY_CAPS:
> return stmmac_tc_query_caps(priv, priv, type_data);
> case TC_SETUP_QDISC_MQPRIO:
> - return stmmac_tc_setup_mqprio(priv, priv, type_data);
> + ret = pm_runtime_resume_and_get(priv->device);
> + if (ret < 0)
> + return ret;
> +
> + ret = stmmac_tc_setup_mqprio(priv, priv, type_data);
> + break;
> case TC_SETUP_BLOCK:
> return flow_block_cb_setup_simple(type_data,
> &stmmac_block_cb_list,
> stmmac_setup_tc_block_cb,
> priv, priv, true);
> case TC_SETUP_QDISC_CBS:
> - return stmmac_tc_setup_cbs(priv, priv, type_data);
> + ret = pm_runtime_resume_and_get(priv->device);
> + if (ret < 0)
> + return ret;
> +
> + ret = stmmac_tc_setup_cbs(priv, priv, type_data);
> + break;
> case TC_SETUP_QDISC_TAPRIO:
> - return stmmac_tc_setup_taprio(priv, priv, type_data);
> + ret = pm_runtime_resume_and_get(priv->device);
> + if (ret < 0)
> + return ret;
> +
> + ret = stmmac_tc_setup_taprio(priv, priv, type_data);
- This is a pre-existing issue, but the patch now explicitly sanctions
running taprio (and cls_u32/cls_flower in the block callback) with only
the bus/CSR clocks resumed, without the rest of the hardware state those
sequences depend on
- This is fixed in the following patch:
https://lore.kernel.org/netdev/20260825-stmmac-est-reapply-after-open-v1-1-dfa80735e0a1@oss.qualcomm.com/
Regards,
Lorenzo
> + break;
> case TC_SETUP_QDISC_ETF:
> return stmmac_tc_setup_etf(priv, priv, type_data);
> default:
> return -EOPNOTSUPP;
> }
> +
> + pm_runtime_put(priv->device);
> +
> + return ret;
> }
>
> static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,
>
> ---
> base-commit: 7cbfb180945ce529608e4d4e24a6d483699fab1e
> change-id: 20260824-stmmac-setup-tc-enable-pm-149aa563d797
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2026-08-27 7:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 17:46 [PATCH net] net: stmmac: hold runtime PM reference in setup_tc Lorenzo Bianconi
2026-08-27 7:11 ` Lorenzo Bianconi [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=ao_jO442V4eG7xd0@lore-desk \
--to=lorenzo.bianconi@oss.qualcomm.com \
--cc=Jose.Abreu@synopsys.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.