Re: [PATCH net 06/11] net: au1000: assign a valid MAC address without platform data

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The code change is correct, but the commit message overstates its
  impact.

--

net: au1000: assign a valid MAC address without platform data

This commit adds a call to eth_hw_addr_random() in the no-platform-data
branch of au1000_probe(). Without it, dev_addr stays all zeroes and
eth_validate_addr() refuses to open the device.

> The supported no-platform-data path leaves dev_addr as all zeroes. The
> device can register but eth_validate_addr() prevents it from opening.

[ ... ]

> Fixes: 7718f2c27dbd ("au1000_eth: use eth_hw_addr_random() instead of random_ether_addr()")

[Severity: Low]
The code change itself looks fine. Is "supported" the right word for this
path, though, and does a Fixes: tag fit here?

As far as I can tell, no in-tree configuration reaches the !pd branch in
au1000_probe(). The only "au1000-eth" platform devices in the tree are in
arch/mips/alchemy/common/platform.c, and both set platform data
statically:

au1xxx_eth0_device:
	.platform_data          = &au1xxx_eth0_platform_data,

au1xxx_eth1_device:
	.platform_data          = &au1xxx_eth1_platform_data,

board-mtx1.c only copies replacement pdata into those static structs
through au1xxx_override_eth_cfg(). au1000_eth_driver has no
of_match_table either, so device tree can't create an instance without
pdata.

On in-tree boards, a missing or invalid PROM MAC leaves pd->mac zeroed.
That case already takes the existing else branch:

		if (is_valid_ether_addr(pd->mac)) {
			eth_hw_addr_set(dev, pd->mac);
		} else {
			/* Set a random MAC since no valid provided by platform_data. */
			eth_hw_addr_random(dev);
		}

So it looks like only out-of-tree board code that registers the device
without platform data can hit the zero MAC failure.

Could the commit message describe this as a latent fix for users without
pdata? Without in-tree users, would net-next without the Fixes: tag be a
better fit than a stable backport?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261027223140.3774570-1-f.fainelli%40gmail.com