From: Lorenzo Bianconi <lorenzo@kernel.org>
To: SAYANTAN NANDY <sayantann11@gmail.com>
Cc: netdev@vger.kernel.org, andrew+netdev@lunn.ch,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, bread.hsu@airoha.com,
sayantan.nandy@airoha.com
Subject: Re: [PATCH net] net: airoha: keep PPE offload when NPU refuses flow stats
Date: Thu, 8 Oct 2026 12:44:29 +0200 [thread overview]
Message-ID: <asd0DfMSLLGu_vbK@lore-desk> (raw)
In-Reply-To: <20261008094828.15458-1-sayantann11@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5874 bytes --]
On Oct 08, SAYANTAN NANDY wrote:
> From: Chad Monroe <chad@monroe.io>
>
> With flow stats enabled, PPE offload setup requests flow statistics
> from the NPU. If the running NPU firmware does not support flow
> counters, the request fails and the current setup path aborts PPE
> offload.
>
> Treat flow statistics as an optional capability so that a failure to
> set up the counters does not prevent normal PPE offload. Record
> whether flow statistics are available and continue PPE initialization
> when the NPU refuses the flow-statistics request.
>
> Also treat a zero NPU statistics address returned by the firmware as a
> refusal. A zero address does not provide a usable counter region and
> must not be passed to the address mapping path.
>
> When flow statistics are unavailable, PPE continues to operate
> without NPU flow counters while retaining normal offload functionality.
>
> This combines the original SmartRG/Airoha fixes for:
> - keeping PPE offload active when the NPU refuses flow statistics
> - treating a zero NPU statistics address as a flow-statistics refusal
>
> Based on the original SmartRG/Airoha work by Chad Monroe:
> 5ce96ab ("SDG-9458: keep PPE offload when NPU refuses flow stats")
> 0ad8528 ("SDG-9458: airoha: treat a zero NPU stats address as a refusal")
> Fixes: b81e0f2b58be ("net: airoha: Add FLOW_CLS_STATS callback support")
> Signed-off-by: Chad Monroe <chad@monroe.io>
> Signed-off-by: SAYANTAN NANDY <sayantann11@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.h | 1 +
> drivers/net/ethernet/airoha/airoha_npu.c | 8 ++++++++
> drivers/net/ethernet/airoha/airoha_ppe.c | 20 +++++++++++++-------
> drivers/net/ethernet/airoha/airoha_regs.h | 2 ++
> 4 files changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 8277c1c87bb3..bd5a94fce843 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -617,6 +617,7 @@ struct airoha_ppe {
>
> void *foe;
> dma_addr_t foe_dma;
> + bool flow_stats;
I agree naming is hard, but I guess we could a more meaningful name, like flow_stats_cap. What do you think?
>
> struct rhashtable l2_flows;
>
> diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
> index 4d3195eb00f7..b32a01dbe06b 100644
> --- a/drivers/net/ethernet/airoha/airoha_npu.c
> +++ b/drivers/net/ethernet/airoha/airoha_npu.c
> @@ -450,6 +450,14 @@ static int airoha_npu_ppe_stats_setup(struct airoha_npu *npu,
> if (err)
> goto out;
>
> + /* The firmware reports success with a zero address when its SRAM
> + * pool has no room left for the counters.
> + */
> + if (!ppe_data->stats_info.npu_stats_addr) {
can it really happen? I guess dmam_alloc_coherent() in airoha_ppe_init()
should fail in this case, right?
> + err = -ENOSPC;
> + goto out;
> + }
> +
> npu->stats = devm_ioremap(npu->dev,
> ppe_data->stats_info.npu_stats_addr,
> size);
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 92611802801e..fbc200614de3 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -37,10 +37,7 @@ static const struct rhashtable_params airoha_l2_flow_table_params = {
>
> static int airoha_ppe_get_num_stats_entries(struct airoha_ppe *ppe)
> {
> - if (!IS_ENABLED(CONFIG_NET_AIROHA_FLOW_STATS))
> - return -EOPNOTSUPP;
> -
> - if (airoha_is_7583(ppe->eth))
> + if (!ppe->flow_stats)
> return -EOPNOTSUPP;
>
> return PPE_STATS_NUM_ENTRIES;
> @@ -144,6 +141,10 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> sram_ppe_num_data_entries =
> PPE_RAM_NUM_ENTRIES_SHIFT(sram_ppe_num_data_entries);
>
> + if (ppe->flow_stats)
> + airoha_fe_rmw(eth, PSE_FC_CFG, PSE_PORT6_SHARE_DIS,
> + FIELD_PREP(PSE_PORT6_SHARE_DIS, 0));
can you please provide more details about it, why is it needed?
Moreover, I guess you could use airoha_fe_clear() here.
> +
> for (i = 0; i < eth->soc->num_ppe; i++) {
> airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
> ppe->foe_dma + sram_tb_size);
> @@ -1456,10 +1457,13 @@ static int airoha_ppe_offload_setup(struct airoha_eth *eth)
> if (ppe_num_stats_entries > 0) {
> err = npu->ops.ppe_init_stats(npu, ppe->foe_stats_dma,
> ppe_num_stats_entries);
> - if (err)
> - goto error_npu_put;
> + if (err) {
> + dev_warn(eth->dev,
> + "NPU firmware refused flow stats setup (%d), offload runs without flow counters\n",
> + err);
can you please try to respect the 79 column width? (I still have old habits :))
> + ppe->flow_stats = false;
> + }
> }
> -
> airoha_ppe_hw_init(ppe);
> airoha_ppe_foe_flow_stats_reset(ppe, npu);
>
> @@ -1608,6 +1612,8 @@ int airoha_ppe_init(struct airoha_eth *eth)
> ppe->dev.priv = ppe;
> ppe->eth = eth;
> eth->ppe = ppe;
> + ppe->flow_stats = IS_ENABLED(CONFIG_NET_AIROHA_FLOW_STATS) &&
> + !airoha_is_7583(eth);
>
> ppe_num_entries = airoha_ppe_get_total_num_entries(ppe);
> foe_size = ppe_num_entries * sizeof(struct airoha_foe_entry);
> diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
> index 442b48c9b991..aee06c058586 100644
> --- a/drivers/net/ethernet/airoha/airoha_regs.h
> +++ b/drivers/net/ethernet/airoha/airoha_regs.h
> @@ -72,6 +72,8 @@
> #define PSE_CFG_OQ_RSV_MASK GENMASK(13, 0)
>
> #define PSE_FQ_CFG 0x008c
> +#define PSE_FC_CFG 0x0098
> +#define PSE_PORT6_SHARE_DIS BIT(22)
> #define PSE_FQ_LIMIT_MASK GENMASK(14, 0)
>
> #define REG_FE_PSE_BUF_SET 0x0090
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-10-08 10:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 9:48 [PATCH net] net: airoha: keep PPE offload when NPU refuses flow stats SAYANTAN NANDY
2026-10-08 9:55 ` netdev-bot+sinfo
2026-10-08 10:44 ` Lorenzo Bianconi [this message]
2026-10-09 5:03 ` [PATCH net v2] " SAYANTAN NANDY
2026-10-09 7:44 ` Lorenzo Bianconi
2026-10-10 5:33 ` netdev-bot+sashiko
2026-10-12 10:05 ` [PATCH net] " netdev-bot+sashiko
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=asd0DfMSLLGu_vbK@lore-desk \
--to=lorenzo@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bread.hsu@airoha.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=netdev@vger.kernel.org \
--cc=sayantan.nandy@airoha.com \
--cc=sayantann11@gmail.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.