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

[Florian Fainelli]

On 10/29/26 09:15, netdev-bot+sashiko@xxxxxxxxxx wrote:
> 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?

Agreed that “supported” overstates the in-tree impact. I’ll describe 
this as a latent regression in the no-platform-data fallback.

I’ll retain the Fixes tag because that commit removed the unconditional 
random-address initialization, introducing this behavior.
--
Florian