[PATCH net-next v3 0/3] net: rss: Consider RSS not supported when key and indir sizes are 0

[PATCH net-next v3 0/3] net: rss: Consider RSS not supported when key and indir sizes are 0

[Maxime Chevallier]

Hi,

This series follows what used to be an stmmac-only series to handle
devices that don't support RSS but still provice the associated ethtool
ops.

There are a few drivers out there that populate the RSS ethtool ops, but
don't always support RSS. stmmac and mvpp2 are such examples.

Following discussions with Jakub on V2, patch 1 makes so that returning
a 0-length key and a 0-size indirection table means "we don't do RSS".

Patch 2 introduces a helper to check for RSS support in stmmac, and
Patch 3 uses it. Patch 3 has been reworked so I haven't applied the
review tags, sorry about that Joe, Lorenzo and Nicolai :( I've drop the
-EOPNOTSUPP return from the rxfh ops as we return 0 on the sizes.

V3:
 - Add patch 1,
 - No changes on patch 2
 - Removed the -EOPNOTSUPP returns on patch 3

V2:
https://lore.kernel.org/r/20260928145043.1228968-1-maxime.chevallier@bootlin.com
 - target net-next
 - Add a dedicated helper, following Nicolai's review.

V1: https://lore.kernel.org/netdev/20260926093343.292181-1-maxime.chevallier@bootlin.com/#t

Maxime Chevallier (3):
  net: rss: Require indir table size or hash key size to support RSS
  net: stmmac: Introduce a helper to check RSS support
  net: stmmac: Don't set or get RSS parameters when not supported

 drivers/net/ethernet/stmicro/stmmac/stmmac.h         | 5 +++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 ++++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c    | 4 ++--
 net/ethtool/ioctl.c                                  | 6 ++++++
 net/ethtool/rss.c                                    | 7 +++++--
 5 files changed, 24 insertions(+), 4 deletions(-)

-- 
2.55.0

[PATCH net-next v3 1/3] net: rss: Require indir table size or hash key size to support RSS

[Maxime Chevallier]

A point can be made that devices that report a 0-size indirection table
and 0-length key size don't really support RSS. Let's return -EOPNOTSUPP
in that case, and skip these devices during DUMP requests.

This however also reports -ENOTSUPP for devices that only supports flow
hash fields ops now.

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 net/ethtool/ioctl.c | 6 ++++++
 net/ethtool/rss.c   | 7 +++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 27b0e2e275dc..d32b403c8d3a 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -1444,6 +1444,9 @@ static noinline_for_stack int ethtool_get_rxfh(struct net_device *dev,
 	if (ops->get_rxfh_key_size)
 		rxfh_dev.key_size = ops->get_rxfh_key_size(dev);
 
+	if (!rxfh_dev.indir_size && !rxfh_dev.key_size)
+		return -EOPNOTSUPP;
+
 	if (copy_from_user(&rxfh, useraddr, sizeof(rxfh)))
 		return -EFAULT;
 	user_indir_size = rxfh.indir_size;
@@ -1554,6 +1557,9 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
 	if (ops->get_rxfh_key_size)
 		dev_key_size = ops->get_rxfh_key_size(dev);
 
+	if (!dev_indir_size && !dev_key_size)
+		return -EOPNOTSUPP;
+
 	if (copy_from_user(&rxfh, useraddr, sizeof(rxfh)))
 		return -EFAULT;
 
diff --git a/net/ethtool/rss.c b/net/ethtool/rss.c
index d4a1a4724b67..cb9bead0cedd 100644
--- a/net/ethtool/rss.c
+++ b/net/ethtool/rss.c
@@ -129,6 +129,9 @@ rss_get_data_alloc(struct net_device *dev, struct rss_reply_data *data)
 	if (ops->get_rxfh_key_size)
 		data->hkey_size = ops->get_rxfh_key_size(dev);
 
+	if (!data->indir_size && !data->hkey_size)
+		return -EOPNOTSUPP;
+
 	indir_bytes = data->indir_size * sizeof(u32);
 	total_size = indir_bytes + data->hkey_size;
 	rss_config = kzalloc(total_size, GFP_KERNEL);
@@ -449,7 +452,7 @@ rss_dump_one_dev(struct sk_buff *skb, struct netlink_callback *cb,
 
 	if (!ctx->ctx_idx) {
 		ret = rss_dump_one_ctx(skb, cb, dev, 0);
-		if (ret)
+		if (ret && ret != -EOPNOTSUPP)
 			return ret;
 		ctx->ctx_idx++;
 	}
@@ -457,7 +460,7 @@ rss_dump_one_dev(struct sk_buff *skb, struct netlink_callback *cb,
 	for (; xa_find(&dev->ethtool->rss_ctx, &ctx->ctx_idx,
 		       ULONG_MAX, XA_PRESENT); ctx->ctx_idx++) {
 		ret = rss_dump_one_ctx(skb, cb, dev, ctx->ctx_idx);
-		if (ret)
+		if (ret && ret != -EOPNOTSUPP)
 			return ret;
 	}
 	ctx->ctx_idx = ctx->start_ctx;
-- 
2.55.0

[PATCH net-next v3 2/3] net: stmmac: Introduce a helper to check RSS support

[Maxime Chevallier]

The RSS feature is only available in stmmac if the hardware reports it
through the DMA caps and if the platform glue sets rss_en.

Introduce a helper that checks both.

For now, no platform sets rss_en, but there's interest in the topic so
leave the door open instead of dropping the feature altogether.

No functional changes intended.

Suggested-by: Nicolai Buchwitz <nb@tipi-net.de>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Reviewed-by: Joe Damato <joe@dama.to>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h      | 5 +++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 4fc96b317d79..17991572fd2d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -440,6 +440,11 @@ struct timespec64 stmmac_calc_tas_basetime(ktime_t old_base_time,
 					   ktime_t current_time,
 					   u64 cycle_time);
 
+static inline bool stmmac_rss_is_supported(const struct stmmac_priv *priv)
+{
+	return priv->dma_cap.rssen && priv->plat->rss_en;
+}
+
 #if IS_ENABLED(CONFIG_STMMAC_SELFTESTS)
 void stmmac_selftest_run(struct net_device *dev,
 			 struct ethtool_test *etest, u64 *buf);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0c381ae0d0ff..76f9f5d35253 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3571,7 +3571,7 @@ static void stmmac_mac_config_rx_queues_routing(struct stmmac_priv *priv)
 
 static void stmmac_mac_config_rss(struct stmmac_priv *priv)
 {
-	if (!priv->dma_cap.rssen || !priv->plat->rss_en) {
+	if (!stmmac_rss_is_supported(priv)) {
 		priv->rss.enable = false;
 		return;
 	}
@@ -8100,7 +8100,7 @@ static int __stmmac_dvr_probe(struct device *device,
 	for (i = 0; i < ARRAY_SIZE(priv->rss.table); i++)
 		priv->rss.table[i] = ethtool_rxfh_indir_default(i, rxq);
 
-	if (priv->dma_cap.rssen && priv->plat->rss_en)
+	if (stmmac_rss_is_supported(priv))
 		ndev->features |= NETIF_F_RXHASH;
 
 	ndev->vlan_features |= ndev->features;
-- 
2.55.0

[PATCH net-next v3 3/3] net: stmmac: Don't set or get RSS parameters when not supported

[Maxime Chevallier]

The RSS kselftests fail on stmmac, and this is partly due to the driver
reporting bogus data for the RSS ops :

 - ethtool -x reports an indirection table and a key while the hardware
   doesn't have any of that
 - ethtool -X fails with -EINVAL.

Return a 0 indir size and key size when rss isn't supported, effectively
meaning we don't support RSS here.

Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 1cf0f8820b33..7f2a70575b83 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -927,6 +927,9 @@ static u32 stmmac_get_rxfh_key_size(struct net_device *dev)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 
+	if (!stmmac_rss_is_supported(priv))
+		return 0;
+
 	return sizeof(priv->rss.key);
 }
 
@@ -934,6 +937,9 @@ static u32 stmmac_get_rxfh_indir_size(struct net_device *dev)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 
+	if (!stmmac_rss_is_supported(priv))
+		return 0;
+
 	return ARRAY_SIZE(priv->rss.table);
 }
 
-- 
2.55.0

Re: [PATCH net-next v3 1/3] net: rss: Require indir table size or hash key size to support RSS

[Nicolai Buchwitz]

Hi Maxime

On 2.10.2026 16:28, Maxime Chevallier wrote:
> A point can be made that devices that report a 0-size indirection table
> and 0-length key size don't really support RSS. Let's return 
> -EOPNOTSUPP
> in that case, and skip these devices during DUMP requests.
> 
> This however also reports -ENOTSUPP for devices that only supports flow
> hash fields ops now.

nit: -EOPNOTSUPP

> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>  net/ethtool/ioctl.c | 6 ++++++
>  net/ethtool/rss.c   | 7 +++++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
> index 27b0e2e275dc..d32b403c8d3a 100644
> --- a/net/ethtool/ioctl.c
> +++ b/net/ethtool/ioctl.c
> @@ -1444,6 +1444,9 @@ static noinline_for_stack int 
> ethtool_get_rxfh(struct net_device *dev,
>  	if (ops->get_rxfh_key_size)
>  		rxfh_dev.key_size = ops->get_rxfh_key_size(dev);
> 
> +	if (!rxfh_dev.indir_size && !rxfh_dev.key_size)
> +		return -EOPNOTSUPP;
> +
>  	if (copy_from_user(&rxfh, useraddr, sizeof(rxfh)))
>  		return -EFAULT;
>  	user_indir_size = rxfh.indir_size;
> @@ -1554,6 +1557,9 @@ static noinline_for_stack int 
> ethtool_set_rxfh(struct net_device *dev,
>  	if (ops->get_rxfh_key_size)
>  		dev_key_size = ops->get_rxfh_key_size(dev);
> 
> +	if (!dev_indir_size && !dev_key_size)
> +		return -EOPNOTSUPP;
> +
>  	if (copy_from_user(&rxfh, useraddr, sizeof(rxfh)))
>  		return -EFAULT;
> 
> diff --git a/net/ethtool/rss.c b/net/ethtool/rss.c
> index d4a1a4724b67..cb9bead0cedd 100644
> --- a/net/ethtool/rss.c
> +++ b/net/ethtool/rss.c
> @@ -129,6 +129,9 @@ rss_get_data_alloc(struct net_device *dev, struct 
> rss_reply_data *data)
>  	if (ops->get_rxfh_key_size)
>  		data->hkey_size = ops->get_rxfh_key_size(dev);
> 
> +	if (!data->indir_size && !data->hkey_size)
> +		return -EOPNOTSUPP;
> +
>  	indir_bytes = data->indir_size * sizeof(u32);
>  	total_size = indir_bytes + data->hkey_size;
>  	rss_config = kzalloc(total_size, GFP_KERNEL);
> @@ -449,7 +452,7 @@ rss_dump_one_dev(struct sk_buff *skb, struct 
> netlink_callback *cb,
> 
>  	if (!ctx->ctx_idx) {
>  		ret = rss_dump_one_ctx(skb, cb, dev, 0);
> -		if (ret)
> +		if (ret && ret != -EOPNOTSUPP)
>  			return ret;
>  		ctx->ctx_idx++;
>  	}
> @@ -457,7 +460,7 @@ rss_dump_one_dev(struct sk_buff *skb, struct 
> netlink_callback *cb,
>  	for (; xa_find(&dev->ethtool->rss_ctx, &ctx->ctx_idx,
>  		       ULONG_MAX, XA_PRESENT); ctx->ctx_idx++) {
>  		ret = rss_dump_one_ctx(skb, cb, dev, ctx->ctx_idx);
> -		if (ret)
> +		if (ret && ret != -EOPNOTSUPP)
>  			return ret;
>  	}
>  	ctx->ctx_idx = ctx->start_ctx;

Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>

Thanks,
Nicolai

Re: [PATCH net-next v3 2/3] net: stmmac: Introduce a helper to check RSS support

[Nicolai Buchwitz]

On 2.10.2026 16:28, Maxime Chevallier wrote:
> The RSS feature is only available in stmmac if the hardware reports it
> through the DMA caps and if the platform glue sets rss_en.
> 
> Introduce a helper that checks both.
> 
> For now, no platform sets rss_en, but there's interest in the topic so
> leave the door open instead of dropping the feature altogether.
> 
> No functional changes intended.
> 
> Suggested-by: Nicolai Buchwitz <nb@tipi-net.de>
> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> Reviewed-by: Joe Damato <joe@dama.to>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---

> [...]

Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>

Thanks,
Nicolai

Re: [PATCH net-next v3 3/3] net: stmmac: Don't set or get RSS parameters when not supported

[Nicolai Buchwitz]

On 2.10.2026 16:28, Maxime Chevallier wrote:
> The RSS kselftests fail on stmmac, and this is partly due to the driver
> reporting bogus data for the RSS ops :
> 
>  - ethtool -x reports an indirection table and a key while the hardware
>    doesn't have any of that
>  - ethtool -X fails with -EINVAL.
> 
> Return a 0 indir size and key size when rss isn't supported, 
> effectively
> meaning we don't support RSS here.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---

> [...]

Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>

Thanks,
Nicolai

Re: [PATCH net-next v3 1/3] net: rss: Require indir table size or hash key size to support RSS

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 (1) · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The new zero-size check is in the shared helper
  rss_get_data_alloc().
- [Low] The commit message gets the side effect wrong in two ways.

Pre-existing issues:
- [Medium] This problem wasn't introduced by this patch, but on 32-bit
  kernels the RSS dump cursor in rss_dump_one_dev() can wrap.

--

net: rss: Require indir table size or hash key size to support RSS

This commit makes the ethtool ioctl (GRSSH/SRSSH) and netlink RSS paths
return -EOPNOTSUPP when a device reports both a zero-size indirection
table and a zero-length hash key. The netlink dump path now skips such
devices instead of aborting.

> This however also reports -ENOTSUPP for devices that only supports flow
> hash fields ops now.

[Severity: Low]
Is this description accurate? The new checks return -EOPNOTSUPP, not
-ENOTSUPP. ENOTSUPP is a kernel-internal errno that userspace should never
see.

Are flow-hash-only devices really the ones affected? Devices without
->get_rxfh were already rejected before this patch:

net/ethtool/rss.c:rss_prepare_data() {
    ...
	ops = dev->ethtool_ops;
	if (!ops->get_rxfh)
		return -EOPNOTSUPP;
    ...
}

rss_dump_one_dev() already skipped them. rss_prepare() still returns 0 for
them on RSS_SET.

The devices whose behaviour changes implement ->get_rxfh but report
indir_size == 0 and key_size == 0 at runtime. One in-tree example is
sfc/falcon. It has no get_rxfh_key_size op, and its indir size can be 0:

drivers/net/ethernet/sfc/falcon/ethtool.c:ef4_ethtool_get_rxfh_indir_size() {
    ...
	return ((ef4_nic_rev(efx) < EF4_REV_FALCON_B0 ||
		 efx->n_rx_channels == 1) ?
		0 : ARRAY_SIZE(efx->rx_indir_table));
}

The commit message also doesn't mention that ETHTOOL_GRSSH and
ETHTOOL_SRSSH now return -EOPNOTSUPP for these devices, through
ethtool_get_rxfh() and ethtool_set_rxfh(). Before this patch, GRSSH still
returned hfunc (for example ETH_RSS_HASH_TOP) and input_xfrm for them.

Could the commit message say which devices are affected, and mention the
ioctl change?

> diff --git a/net/ethtool/rss.c b/net/ethtool/rss.c
> index d4a1a4724b675..cb9bead0cedd1 100644
> --- a/net/ethtool/rss.c
> +++ b/net/ethtool/rss.c
> @@ -129,6 +129,9 @@ rss_get_data_alloc(struct net_device *dev, struct rss_reply_data *data)
>  	if (ops->get_rxfh_key_size)
>  		data->hkey_size = ops->get_rxfh_key_size(dev);
>  
> +	if (!data->indir_size && !data->hkey_size)
> +		return -EOPNOTSUPP;
> +

[Severity: Medium]
rss_get_data_alloc() is shared by RSS_GET, RSS_SET and RSS_CREATE. Does
this drop flow-hash reporting for devices that have ->get_rxfh but report
0/0 sizes?

rss_prepare() fills in the flow hash first. It only returns early when
->get_rxfh is NULL:

net/ethtool/rss.c:rss_prepare() {
	rss_prepare_flow_hash(request, dev, data, info);

	/* Coming from RSS_SET, driver may only have flow_hash_fields ops */
	if (!dev->ethtool_ops->get_rxfh)
		return 0;

	if (request->rss_context)
		return rss_prepare_ctx(request, dev, data, info);
	return rss_prepare_get(request, dev, data, info);
}

For such a device with rss_context == 0, the path is now:

rss_prepare()
  rss_prepare_flow_hash()   <- data->flow_hash filled, has_flow_hash set
  rss_prepare_get()
    rss_get_data_alloc()    <- returns -EOPNOTSUPP

The flow hash that was already collected is thrown away. Before this
patch, kzalloc(0) returned ZERO_SIZE_PTR and get_rxfh() succeeded. The
reply then included ETHTOOL_A_RSS_HFUNC and the ETHTOOL_A_RSS_FLOW_HASH
nest.

Take sfc/falcon B0 with a single RX channel. ef4_ethtool_get_rxfh_fields()
reports real TCP/IPv4 hash fields there. RSS_GET now fails anyway, and the
device silently drops out of RSS dumps.

On the RSS_SET side, ethnl_rss_set() returns early on this error:

	ret = rss_prepare(request, dev, &data, info);
	if (ret)
		return ret;

So requests that only change ETHTOOL_A_RSS_FLOW_HASH or
ETHTOOL_A_RSS_INPUT_XFRM are rejected before they reach
ethnl_set_rss_fields(). Neither of those needs an indirection table or a
key. rss_set_prep_indir() already rejected a zero-size INDIR attribute on
its own.

I couldn't find an in-tree driver where the SET side does real harm
today:

  - vmxnet3 without RSS already returns -EOPNOTSUPP from its flow-field
    ops.
  - falcon has no set_rxfh_fields.
  - virtio_net without RSS/HASH_REPORT only accepts no-op set_hashflow
    changes.

The GET-side loss is concrete, though.

The ioctl equivalents ETHTOOL_GRXFH and ETHTOOL_SRXFH have no such size
check and keep working on the same device. They go through
ethtool_get_rxfh_fields() and ethtool_set_rxfh_fields().
Documentation/networking/ethtool-netlink.rst maps those commands to
ETHTOOL_MSG_RSS_GET and ETHTOOL_MSG_RSS_SET. Is it intended that netlink
and ioctl now disagree here?

>  	indir_bytes = data->indir_size * sizeof(u32);
>  	total_size = indir_bytes + data->hkey_size;
>  	rss_config = kzalloc(total_size, GFP_KERNEL);

[ ... ]

> @@ -457,7 +460,7 @@ rss_dump_one_dev(struct sk_buff *skb, struct netlink_callback *cb,
>  	for (; xa_find(&dev->ethtool->rss_ctx, &ctx->ctx_idx,
>  		       ULONG_MAX, XA_PRESENT); ctx->ctx_idx++) {
>  		ret = rss_dump_one_ctx(skb, cb, dev, ctx->ctx_idx);
> -		if (ret)
> +		if (ret && ret != -EOPNOTSUPP)
>  			return ret;
>  	}
>  	ctx->ctx_idx = ctx->start_ctx;

[Severity: Medium]
This isn't a bug introduced by this patch, but can ctx->ctx_idx wrap here
on 32-bit kernels?

ctx_idx is an unsigned long. The loop increments it after each context
without checking for ULONG_MAX.

RSS_CREATE accepts an explicit ETHTOOL_A_RSS_CONTEXT of U32_MAX, since the
policy is NLA_POLICY_MIN(NLA_U32, 1). When ops->rxfh_max_num_contexts is
0, ethnl_rss_create_validate() applies no upper bound. sfc's
efx_ethtool_ops is one such case:

	if (ops->rxfh_max_num_contexts &&
	    ops->rxfh_max_num_contexts <= rss_context) {

ethnl_rss_create_doit() then inserts that exact ID with xa_insert(). This
skips the limit - 1 bound that xa_alloc() applies to automatically
allocated IDs.

On 32-bit, U32_MAX equals ULONG_MAX. After that context is emitted,
ctx->ctx_idx++ wraps to 0 and xa_find() returns already-emitted contexts
again. When the skb fills, -EMSGSIZE keeps the cursor and the dump
resumes, so the cycle repeats.

Would the RSS_GET dump then never end for userspace? Creating such a
context needs admin privileges in the netns.

The -EOPNOTSUPP change in this patch doesn't touch the cursor arithmetic.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261002142806.1299041-1-maxime.chevallier%40bootlin.com

Re: [PATCH net-next v3 3/3] net: stmmac: Don't set or get RSS parameters when not supported

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit fixes a user-visible bug that goes back to 2019 but
  has no Fixes: trailer.

--

net: stmmac: Don't set or get RSS parameters when not supported

This commit makes stmmac_get_rxfh_key_size() and
stmmac_get_rxfh_indir_size() return 0 when stmmac_rss_is_supported() is
false. The ethtool core then reports -EOPNOTSUPP instead of returning a
bogus key and indirection table for ethtool -x, or failing with -EINVAL
for ethtool -X.

> The RSS kselftests fail on stmmac, and this is partly due to the driver
> reporting bogus data for the RSS ops :
>
>  - ethtool -x reports an indirection table and a key while the hardware
>    doesn't have any of that
>  - ethtool -X fails with -EINVAL.
>
> Return a 0 indir size and key size when rss isn't supported, effectively
> meaning we don't support RSS here.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

[Severity: Low]
The commit message describes a user-visible bug fix, but there is no
Fixes: tag. Should one be added?

Both callbacks were added by commit 76067459c686 ("net: stmmac: Implement
RSS and enable it in XGMAC core"). Since then they have returned
sizeof(priv->rss.key) and ARRAY_SIZE(priv->rss.table) whether or not RSS
is supported.

Because those sizes were non-zero, ethtool_get_rxfh() and
ethtool_set_rxfh() in net/ethtool/ioctl.c, and rss_prepare_data() in
net/ethtool/rss.c, never reached their -EOPNOTSUPP path:

    if (!rxfh_dev.indir_size && !rxfh_dev.key_size)
        return -EOPNOTSUPP;

Instead, ethtool -x reached stmmac_get_rxfh() and returned the defaults
set at probe time. ethtool -X went through
stmmac_set_rxfh()->stmmac_rss_configure(), and stmmac_do_callback()
returns -EINVAL there when the core has no rss_configure callback.

The previous patch, "net: stmmac: Introduce a helper to check RSS
support", notes that no platform sets rss_en yet. That means this affects
every stmmac user today.

Would something like this help stable maintainers?

    Fixes: 76067459c686 ("net: stmmac: Implement RSS and enable it in XGMAC core")

Any backport would also need the helper patch from the previous commit,
which also has no Fixes: tag.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261002142806.1299041-1-maxime.chevallier%40bootlin.com