Re: [PATCH net-next v5 11/12] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Probe fails completely when devices use randomly generated MAC addresses due to strict MSB validation.
- [Medium] Strict MAC address MSB validation creates a configuration deadlock, preventing users from modifying MAC addresses.
--

commit d9f17b062a5dbe5adb3be07d9c3f501106b25dd8
Author: Lorenzo Bianconi <lorenzo@kernel.org>

net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration

This commit extends the hardware MAC address configuration in the airoha
Ethernet driver to support multiple LAN or WAN interfaces. It calculates
the minimum and maximum lower MAC address bytes across all devices with the
same configuration, and enforces that they share the same upper 3 MAC
address bytes.

> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index fa37dbd76d579..623cac42dfb71 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> -static void airoha_set_macaddr(struct airoha_gdm_dev *dev, const u8 *addr)
> +static int airoha_set_macaddr(struct airoha_gdm_dev *dev, const u8 *addr)
>  {
>  	struct airoha_eth *eth = dev->eth;
> -	u32 val, reg;
> +	u8 ref_addr[ETH_ALEN] = {};
> +	u32 reg, val, lmin, lmax;
> +	int i;
> +
> +	lmin = (addr[3] << 16) | (addr[4] << 8) | addr[5];
> +	lmax = lmin;
> +
> +	for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
[ ... ]
> +			ether_addr_copy(ref_addr, netdev->dev_addr);
> +			val = (netdev->dev_addr[3] << 16) |
> +			      (netdev->dev_addr[4] << 8) | netdev->dev_addr[5];
> +			if (val < lmin)
> +				lmin = val;
> +			if (val > lmax)
> +				lmax = val;
> +		}
> +	}
> +
> +	if (!is_zero_ether_addr(ref_addr) && memcmp(ref_addr, addr, 3)) {
> +		/* According to the HW design, hw mac address MS bits
> +		 * must be the same for each net_device with the same
> +		 * LAN/WAN configuration.
> +		 */
> +		return -EINVAL;
> +	}

Does this strict MSB validation cause device initialization to fail if the
device tree does not provide MAC addresses?

If the driver falls back to assigning addresses via eth_hw_addr_random(),
the randomly generated addresses will almost certainly have different upper
3 bytes. Will this cause airoha_set_macaddr() to return -EINVAL for the
second interface, aborting initialization and failing the driver probe?

Could this also create a configuration deadlock when users try to change
MAC addresses from userspace?

Since tools like 'ip link' configure interfaces sequentially, attempting to
change eth0 to a new OUI would be rejected because its new MSBs won't match
eth1's current MSBs. Attempting to change eth1 first would similarly fail
against eth0. Is there a way for users to successfully change the MAC
address MSBs once the interfaces are initialized?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260509-airoha-eth-multi-serdes-v5-0-805e38edc2aa@kernel.org?part=11