Re: [PATCH net-next 02/14] net: enetc: extract common helpers for MAC hash filter configuration

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Preexisting 32-bit truncation bug in VLAN hash filter configuration identical to the one fixed for MAC hash filters.
--

commit 2d2b1381169047a47aed6dfbbe75eac22a3d3710
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: extract common helpers for MAC hash filter configuration

This patch extracts the MAC hash filter configuration code, which is
identical between ENETC v1 and v4 hardware, into common helper functions
in enetc_pf_common.c. It also replaces direct bitmap dereferences with
bitmap_to_arr64() to ensure correct 64-bit conversion on 32-bit systems.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> index a97d2e2dd07b7..db2a800a7aaf0 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c

[ ... ]

> @@ -147,11 +120,15 @@ static void enetc_sync_mac_filters(struct enetc_pf *pf)
>  				 err);
>  		}
>  
> +		bitmap_to_arr64(&hash, f->mac_hash_table,
> +				ENETC_MADDR_HASH_TBL_SZ);
>  		/* hash table filter, clear EM filter for UC entries */
> -		if (i == UC)
> +		if (i == UC) {
>  			enetc_clear_mac_flt_entry(si, pos);
> -
> -		enetc_set_mac_ht_flt(si, 0, i, *f->mac_hash_table);
> +			enetc_set_si_uc_hash_filter(si, 0, hash);

[Severity: High]
This is a pre-existing issue, but I noticed this patch correctly uses
bitmap_to_arr64() to handle 32-bit architectures when passing the 64-bit MAC
hash table to enetc_set_si_uc_hash_filter().

Does the same 32-bit truncation issue happen with the VLAN hash filter
configuration? Looking at enetc_vlan_rx_add_vid() and enetc_vlan_rx_del_vid()
in drivers/net/ethernet/freescale/enetc/enetc_pf_common.c, it appears they
pass the bitmap directly:

enetc_set_si_vlan_ht_filter(pf->si, 0, *pf->vlan_ht_filter);

Since pf->vlan_ht_filter is also defined as a DECLARE_BITMAP of size 64,
wouldn't dereferencing it as *pf->vlan_ht_filter evaluate to a 32-bit
unsigned long on 32-bit architectures?

If so, this would zero-extend the value when passed to the u64 hash parameter,
clearing the upper 32 bits of the hardware VLAN hash filter register and
breaking VLAN filtering for any VID that hashes to bits 32-63.

Should a similar bitmap_to_arr64() fix be applied for the VLAN hash filter?

> +		} else {
> +			enetc_set_si_mc_hash_filter(si, 0, hash);
> +		}
>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630072036.382761-1-wei.fang@oss.nxp.com?part=2