Re: [PATCH net] net: stmmac: Don't set or get RSS parameters when not supported

[Nicolai Buchwitz <nb@tipi-net.de>]

Hi Maxime

On 26.9.2026 11:33, 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.
> 
> Let's return early in the rss ops if we know the hardware and platform
> don't support RSS.
> 
> Note that RSS is currently not supported on any devices upstream, so
> code that was already useless is now effectively dead. It has been the
> case since 2019 when the code was added, as platforms need to set 
> rss_en
> in their plat data, and no glue ever did that.
> 
> Russell King ran a poll in february 2026 [1] asking if the code should
> be dropped, without any reply going in either direction.
> 
> Jitendra Vegiraju from Broadcom sent 9 iterations of a Broadcom PCIe 
> glue
> driver [2] that actually sets rss_en = 1, so there's some hope that 
> this
> may be used in the future.
> 
> [1] : 
> https://lore.kernel.org/netdev/aYd4BkAeNW6d0iIC@shell.armlinux.org.uk/
> [2] : 
> https://lore.kernel.org/netdev/20260402213629.1996133-1-jitendra.vegiraju@broadcom.com/
> 
> Fixes: 76067459c686 ("net: stmmac: Implement RSS and enable it in XGMAC 
> core")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
> Jitendra, do you have plans to continue iterating on the BCM8958x glue 
> ?
> 
> Thanks,
> 
> Maxime
> 
>  drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> index 1be5310ca766..4e917a448271 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 (!priv->dma_cap.rssen || !priv->plat->rss_en)

Should this pattern become a helper? Counting 6 instances so far.

> +		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 (!priv->dma_cap.rssen || !priv->plat->rss_en)
> +		return 0;
> +
>  	return ARRAY_SIZE(priv->rss.table);
>  }
> 
> @@ -943,6 +949,9 @@ static int stmmac_get_rxfh(struct net_device *dev,
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  	int i;
> 
> +	if (!priv->dma_cap.rssen || !priv->plat->rss_en)
> +		return -EOPNOTSUPP;

Not a blocker, but a full netlink RSS dump (like the one in rss_ctx.py)
now stops at this device. Naybe rss_dump_one_dev() should skip 
-EOPNOTSUPP
like ethnl_default_dumpit() does?

> +
>  	if (rxfh->indir) {
>  		for (i = 0; i < ARRAY_SIZE(priv->rss.table); i++)
>  			rxfh->indir[i] = priv->rss.table[i];
> @@ -962,6 +971,9 @@ static int stmmac_set_rxfh(struct net_device *dev,
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  	int i;
> 
> +	if (!priv->dma_cap.rssen || !priv->plat->rss_en)
> +		return -EOPNOTSUPP;
> +
>  	if (rxfh->hfunc != ETH_RSS_HASH_NO_CHANGE &&
>  	    rxfh->hfunc != ETH_RSS_HASH_TOP)
>  		return -EOPNOTSUPP;

Thanks,
Nicolai