RE: [PATCH v2 net-next 12/12] net: enetc: dynamically allocate rxmsg based on VF count

[Wei Fang]

The below issues reported by Sashiko are false positives. The ENETC v4
(i.MX series) uses a different driver (enetc4_pf.c). enetc_pf.c and
ENETC_PSIPVMR_SET_VP and are only used by the ENETC v1 driver,
and ENETC v1 supports 2 VFs, so the issues do not actually exist.

Sashio:

>     i.MX94 standalone ENETC: 0 VFs

This is a pre-existing issue, but if a device supports 0 VFs and reports
more than 8 hardware rings during probe, will this result in a division by
zero?

In enetc_port_si_configure(), the driver reserves 8 rings for the PF and
distributes the rest to the VFs:

drivers/net/ethernet/freescale/enetc/enetc_pf.c:enetc_port_si_configure() {
	...
	if (num_rings)
		num_rings -= ENETC_PF_NUM_RINGS;
	...
	if (num_rings) {
		num_rings /= pf->total_vfs;
		val |= ENETC_PSICFGR0_SET_TXBDR(num_rings);
		val |= ENETC_PSICFGR0_SET_RXBDR(num_rings);
	}
	...
}

If pf->total_vfs is 0 and there are remaining rings, the division by zero
will cause a kernel panic.

>     i.MX94 internal ENETC:   3 VFs

This isn't a bug introduced by this patch, but since 3 VFs means there are
4 Station Interfaces (1 PF + 3 VFs) in total, will VLAN promiscuous mode
work for the 3rd VF?

The ENETC_PSIPVMR_SET_VP() macro uses a hardcoded 0x7 mask (3 bits), which
covers only the first 3 Station Interfaces:

drivers/net/ethernet/freescale/enetc/enetc_hw.h:
#define ENETC_PSIPVMR_SET_VP(simap)	((simap) & 0x7)

Because of this mask, the 4th Station Interface (the 3rd VF mapped to bit 3)
is silently dropped from the VLAN promiscuous mode configuration.