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

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

On 9/29/26 10:48, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 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] This patch makes stmmac_get_rxfh() in
>   drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c return…
> - [Low] The commit message describes a user-visible bug: on stmmac
>   devices without RSS, 'ethtool -x reports an indirection table and a…
> 
> --
> 
> net: stmmac: Don't set or get RSS parameters when not supported
> 
> This commit changes the stmmac ethtool RSS ops to return early when
> stmmac_rss_is_supported() is false. The key and indirection sizes now
> report 0, and get_rxfh/set_rxfh return -EOPNOTSUPP. The aim is to stop
> reporting bogus RSS data and to make the RSS kselftests work on stmmac.
> 
>> 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.
>>
>> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> 
> [Severity: Low]
> The commit message describes a bug that users can see, but there is no
> Fixes: tag.
> 
> Blame shows that the unconditional stmmac_get_rxfh_key_size(),
> stmmac_get_rxfh_indir_size(), stmmac_get_rxfh() and stmmac_set_rxfh()
> logic came from commit 76067459c686. The later refactor fb6e30a72539 only
> moved these functions to the ethtool_rxfh_param API.
> 
> Should this carry the following tag?
> 
> Fixes: 76067459c686 ("net: stmmac: Implement RSS and enable it in XGMAC core")

targetting net-next, problem always existed, doesn't crash the kernel,
it's just returning bogus harmless stuff

> 
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
>> index 1cf0f8820b33..56019683f399 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> 
> [ ... ]
> 
>> @@ -943,6 +949,9 @@ static int stmmac_get_rxfh(struct net_device *dev,
>>  	struct stmmac_priv *priv = netdev_priv(dev);
>>  	int i;
>>  
>> +	if (!stmmac_rss_is_supported(priv))
>> +		return -EOPNOTSUPP;
>> +
> 
> [Severity: Medium]
> Does this -EOPNOTSUPP break namespace-wide ETHTOOL_MSG_RSS_GET dumps?

This was reported by Nicolai already, and other drivers report -EOPNOTSUPP
here.

If we address that, I'd say we do that in the RSS ethnl code.

Maxime