Re: [PATCH v4 net-next 12/14] net: enetc: remove redundant num_vsi field from enetc_port_caps

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware ring overallocation when CONFIG_PCI_IOV is disabled due to uninitialized VSI PSICFGR0 registers.
--

--- Patch [12]: [PATCH v4 net-next 12/14] net: enetc: remove redundant num_vsi field from enetc_port_caps ---
commit d0ac7548c05e5390933f00261830b4e5d8ae719a
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: remove redundant num_vsi field from enetc_port_caps

This commit removes the num_vsi field from the enetc_port_caps structure
and replaces its usage with pf->total_vfs. The justification is that
pf->total_vfs already reflects the number of VFs that can actually be used.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
> index cab79f81d6fe0..fcfbabb29d22e 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
[ ... ]
> @@ -255,34 +254,35 @@ static void enetc4_default_rings_allocation(struct enetc_pf *pf)
>  {
>  	struct enetc_hw *hw = &pf->si->hw;
>  	u32 num_rx_bdr, num_tx_bdr, val;
> +	int num_vfs = pf->total_vfs;
>  	u32 vf_tx_bdr, vf_rx_bdr;
>  	int i, rx_rem, tx_rem;
>  
> -	if (pf->caps.num_rx_bdr < ENETC_SI_MAX_RING_NUM + pf->caps.num_vsi)
> -		num_rx_bdr = pf->caps.num_rx_bdr - pf->caps.num_vsi;
> +	if (pf->caps.num_rx_bdr < ENETC_SI_MAX_RING_NUM + num_vfs)
> +		num_rx_bdr = pf->caps.num_rx_bdr - num_vfs;
>  	else
>  		num_rx_bdr = ENETC_SI_MAX_RING_NUM;
>  
> -	if (pf->caps.num_tx_bdr < ENETC_SI_MAX_RING_NUM + pf->caps.num_vsi)
> -		num_tx_bdr = pf->caps.num_tx_bdr - pf->caps.num_vsi;
> +	if (pf->caps.num_tx_bdr < ENETC_SI_MAX_RING_NUM + num_vfs)
> +		num_tx_bdr = pf->caps.num_tx_bdr - num_vfs;
>  	else
>  		num_tx_bdr = ENETC_SI_MAX_RING_NUM;
>  
>  	val = enetc4_psicfgr0_val_construct(false, num_tx_bdr, num_rx_bdr);
>  	enetc_port_wr(hw, ENETC4_PSICFGR0(0), val);
>  
> -	if (!pf->caps.num_vsi)
> +	if (!num_vfs)
>  		return;

[Severity: High]
In enetc4_default_rings_allocation(), when num_vfs is 0 (such as when
CONFIG_PCI_IOV is disabled), this returns early without zeroing the ring
allocations in the VSIs' PSICFGR0 registers.

Because num_vfs is 0 instead of the true physical VSI count, the PF is
allocated the maximum possible hardware rings.

If these VSI registers retain non-zero values (e.g., from firmware defaults
or after a warm reboot), won't the sum of configured rings across the PF and
VSIs strictly exceed the physical hardware capacity?

Could this lead to memory corruption within the ENETC device's internal
SRAM or cause DMA issues due to overlapping BD ring structures?

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