Hi :-) On Fri, 17 May 2024 17:13:18 +0100 Conor Dooley <conor@xxxxxxxxxx> wrote: > On Fri, May 17, 2024 at 04:07:08PM +0200, Andrew Lunn wrote: > > On Fri, May 17, 2024 at 02:39:07PM +0200, Leon M. Busch-George > > wrote: > > > > > Restore the ability to set addresses through the device tree by > > > adding an option to ignore the 'local-mac-address' property. > > > > I'm not convinced you are fixing the right thing here. > > > > To me, this is the bootloader which is broken. You should be fixing > > the bootloader. > > IMO this is firmly in the "setting software policy" category of > properties and is therefore not really welcome. > If we can patch the DT provided to the kernel with this property, how > come the bootloader cannot be changed to stop patching the random MAC > address in the first place? .. and .. On Fri, May 17, 2024 at 04:07:08PM +0200, Andrew Lunn wrote: > I'm not convinced you are fixing the right thing here. > > To me, this is the bootloader which is broken. You should be fixing > the bootloader. I agree changing the bootloader is the better approach and I'm absolutely willing to accept if this isn't the way of the kernel. Also, since posting this, I was made aware that it's possible to remove the 'ethernet0' alias to stop the unwanted activity. There's no longer much reason for me to work on this. There's only that slight annoyance of configuring a mac address assignment on the device tree and the kernel silently ignoring it. But, I guess, that doesn't happen if the proprietary bootloader isn't creating "local-mac-address" properties - rather than only changing existing ones (which is what mainline U-Boot does). On altering/replacing the bootloader: It is not always possible or feasible to replace proprietary bootloaders on proprietary hardware. Many of the routers I work with effectively become bricks if the bootloader doesn't work. If it has one of these chunky DIP SPI NORs, then might be possible to restore using the right hardware but the two devices mentioned in the commit both have QFP NAND that I cannot read without the help of software running on the board. > One concession might be, does the bootloader correctly generate a > random MAC address? i.e. does it have the locally administered bit > set? If that bit is set, and there are other sources of a MAC > address, then it seems worth while checking them to see if there is > a better MAC address available, which as global scope. I like that idea! All the addresses that were generated on a few reboots for testing have it set. Let's hope we wont get a reason to implement that too soon :-D kind regards, Leon
