Re: [PATCH v2 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] Pre-existing logic bug: Fallback to hash-based filtering fails for exact match (EM) MAC addresses because the hash table is not populated.
--

commit 0373b31ab4e7a0beb8461d5ceb05e09d7d5b61ab
Author: Wei Fang <wei.fang@nxp.com>
Date:   Thu Jul 2 02:57:02 2026 +0000

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

The patch extracts enetc_set_si_uc_hash_filter() and 
enetc_set_si_mc_hash_filter() into enetc_pf_common.c. This allows sharing 
the MAC hash filter configuration between ENETC v1 and v4 drivers, and 
removes redundant hardware-specific functions.

> 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
[ ... ]
> @@ -135,7 +108,7 @@ static void enetc_sync_mac_filters(struct enetc_pf *pf)
>  		if (em) {
>  			int err;
>  
> -			enetc_clear_mac_ht_flt(si, 0, UC);
> +			enetc_set_si_uc_hash_filter(si, 0, 0);
>  
>  			err = enetc_set_mac_flt_entry(si, pos, f->mac_addr,
>  						      BIT(0));
> @@ -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 does this fallback path actually work for
exact match MAC addresses?

In enetc_pf_set_rx_mode(), when configuring a single unicast MAC address,
enetc_add_mac_addr_em_filter() is called, but the hash table population is
explicitly skipped:

enetc_pf_set_rx_mode() {
	...
	em = (netdev_uc_count(ndev) == 1);
	netdev_for_each_uc_addr(ha, ndev) {
		if (em) {
			enetc_add_mac_addr_em_filter(filter, ha->addr);
			break;
		}
		enetc_add_mac_addr_ht_filter(filter, ha->addr);
	}
	...
}

Because of this, mac_hash_table remains empty for the EM filter.

If enetc_set_mac_flt_entry() fails in enetc_sync_mac_filters(), the driver
warns "fallback to HT filt" and falls through to this block. However, since
the hash table was never populated, the derived hash is 0.

Doesn't this result in programming an empty hash filter, which will silently
drop all packets for this intended MAC address instead of falling back to
hash-based filtering?

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

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