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

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hi Nicolai,

On 9/26/26 20:41, Nicolai Buchwitz wrote:
> 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.

yeah why not :)

> 
>> +        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?
there are other drivers that report -EOPNOTSUPP, we could have that as
a separate patch yeah

Thanks for looking at this,

Maxime