Re: [PATCH v4 net-next 12/15] net: enetc: add VF support for i.MX94 and i.MX95

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ENETC4 VF incorrectly exposes `enetc_get_regs` which reads ENETC1-specific CBDR registers, potentially causing bus errors.
--

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

net: enetc: add VF support for i.MX94 and i.MX95

This commit adds VF support for the i.MX94 and i.MX95 platforms, introducing
the new VF device ID 0xef00, the enetc4 SI ops, and the VF driver data. It
also wires up .sriov_configure for the enetc4 PF driver to allow creation
and teardown of VFs.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
> index 80f0082f6c633..803c5c541a5c1 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc.c
> @@ -3794,6 +3794,13 @@ static const struct enetc_drvdata enetc_vf_data = {
>  	.eth_ops = &enetc_vf_ethtool_ops,
>  };
>  
> +static const struct enetc_drvdata enetc4_vf_data = {
> +	.sysclk_freq = ENETC_CLK_333M,
> +	.tx_csum = true,
> +	.max_frags = ENETC4_MAX_SKB_FRAGS,
> +	.eth_ops = &enetc_vf_ethtool_ops,

[Severity: High]
Does reusing enetc_vf_ethtool_ops for ENETC4 VFs inadvertently expose
enetc_get_regs() on hardware that doesn't support it?

When a user runs ethtool -d on the ENETC4 VF interface, it triggers
enetc_get_regs(). This function iterates over enetc_si_regs and reads
ENETC1-specific Command Buffer Descriptor Ring (CBDR) registers:

drivers/net/ethernet/freescale/enetc/enetc_ethtool.c:enetc_get_regs() {
    ...
    for (i = 0; i < ARRAY_SIZE(enetc_si_regs); i++) {
            *buf++ = enetc_si_regs[i];
            *buf++ = enetc_rd(hw, enetc_si_regs[i]);
    }
    ...
}

Since ENETC4 uses NTMP instead of CBDR, these MMIO offsets are not
implemented. Does reading them trigger a synchronous external abort
(bus error) and cause a kernel panic on ARM architectures?

The PF driver data uses enetc4_pf_ethtool_ops which avoids this, but the VF
data here reuses the ENETC1 ops. Should there be a dedicated
enetc4_vf_ethtool_ops that omits get_regs?

> +};
> +
>  static const struct enetc_platform_info enetc_info[] = {
>  	{ .revision = ENETC_REV_1_0,
>  	  .dev_id = ENETC_DEV_ID_PF,

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