Re: [PATCH v3 net 5/9] net: enetc: fix race condition in VF MAC address configuration

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Incorrect MAC address programming on Big-Endian architectures due to the use of __raw_writel and __raw_writew.
--

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

net: enetc: fix race condition in VF MAC address configuration

This commit introduces a per-VF mutex to serialize access to vf_state and
hardware MAC register updates. This prevents a race condition between the
VF message handler and administrative VF MAC configuration from the host.

Link: https://sashiko.dev/#/patchset/20260511080805.2052495-1-wei.fang%40nxp.com

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> index 09c6420408923..8e11a023d516b 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> @@ -252,8 +252,12 @@ static int enetc_pf_set_vf_mac(struct net_device *ndev, int vf, u8 *mac)
>  		return -EADDRNOTAVAIL;
>  
>  	vf_state = &pf->vf_state[vf];
> +
> +	mutex_lock(&vf_state->lock);
>  	vf_state->flags |= ENETC_VF_FLAG_PF_SET_MAC;
>  	enetc_pf_set_primary_mac_addr(&priv->si->hw, vf + 1, mac);

[Severity: High]
This is a pre-existing issue, but does calling this function cause an
incorrect MAC address to be programmed on big-endian architectures?

Looking at the implementation of enetc_pf_set_primary_mac_addr():

static void enetc_pf_set_primary_mac_addr(struct enetc_hw *hw, int si,
                                          const u8 *addr)
{
        u32 upper = get_unaligned_le32(addr);
        u16 lower = get_unaligned_le16(addr + 4);

        __raw_writel(upper, hw->port + ENETC_PSIPMAR0(si));
        __raw_writew(lower, hw->port + ENETC_PSIPMAR1(si));
}

The function parses the address using get_unaligned_le32() and
get_unaligned_le16(), which convert little-endian bytes to native CPU
byte order. It then writes these values using __raw_writel() and
__raw_writew().

Since the raw I/O accessors do not perform CPU-to-device endianness
byte-swapping, the CPU-endian values are written as-is to the device.
On big-endian architectures, would this cause the bytes to be reversed
from the hardware's perspective and corrupt the MAC address?

Could the driver use the standard writel() and writew() accessors, or
its own enetc_port_wr() wrapper, to ensure proper CPU-to-LE conversion?

> +	mutex_unlock(&vf_state->lock);
> +
>  	return 0;
>  }
>  

[ ... ]

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