Re: [PATCH v2 net-next 01/12] net: enetc: use enetc_set_si_hw_addr() for setting MAC address

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Hardware registers for MAC address configuration are accessed using `__raw_readl` and `__raw_writel` without endianness conversions, causing incorrect MAC addresses on Big Endian systems.
--

commit 9950ab386f64a0d2f5b71b2003e9ca960d52dddd
Author: Wei Fang <wei.fang@nxp.com>
net: enetc: use enetc_set_si_hw_addr() for setting MAC address

This commit replaces enetc_pf_set_primary_mac_addr() with the generic
enetc_set_si_hw_addr() function to prepare for moving MAC address setting
logic to the common driver for reuse.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
> index 76263b8566bb3..c30b5f71efd5e 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
[ ... ]
> @@ -7,13 +7,13 @@
>  
>  #include "enetc_pf_common.h"
>  
> -static void enetc_set_si_hw_addr(struct enetc_pf *pf, int si,
> -				 const u8 *mac_addr)
> +void enetc_set_si_hw_addr(struct enetc_pf *pf, int si, const u8 *mac_addr)
>  {
>  	struct enetc_hw *hw = &pf->si->hw;
>  
>  	pf->ops->set_si_primary_mac(hw, si, mac_addr);

[Severity: High]
This is a pre-existing issue, but does the underlying MAC address
configuration code have an endianness bug on Big Endian systems?

Hardware registers for MAC address configuration are accessed using
__raw_readl() and __raw_writel() without endianness conversions.

The code uses get_unaligned_le32() to read the first 4 bytes of the MAC
address into a host-endian u32. For a MAC address starting with 12:34:56:78,
on a Big Endian CPU this creates the u32 value 0x78563412.

It then uses __raw_writel() to write this u32 to the PCIe memory-mapped
register. __raw_writel() performs a raw host-endian memory store without any
byte swapping. On a Big Endian CPU, 0x78563412 is stored in memory as the
byte sequence 0x78, 0x56, 0x34, 0x12.

Since the PCIe controller interprets the MMIO space as Little Endian, it
reads those bytes back as 0x12345678, completely reversing the MAC address
bytes. Could this break network configuration and communication on Big Endian
systems?

The rest of the driver correctly uses iowrite32() and ioread32()
(via enetc_wr() and enetc_rd()), which handle the host-to-LE conversion
properly.

>  }
> +EXPORT_SYMBOL_GPL(enetc_set_si_hw_addr);
[ ... ]

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