Received-SPF: pass (google.com: domain of linux-kernel+bounces-182635-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 17 May 2024 23:15:43 +0200
From: Leon Busch-George <leon@georgemail.eu>
To: Conor Dooley <conor@kernel.org>, Andrew Lunn <andrew@lunn.ch>
Cc: linux-kernel@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
 devicetree@vger.kernel.org, netdev@vger.kernel.org, Matthias Brugger
 <matthias.bgg@gmail.com>
Subject: Re: [PATCH 1/2] net: add option to ignore 'local-mac-address'
 property
Message-ID: <20240517231543.325d6838@couch-potassium>
In-Reply-To: <20240517-unscrew-handsfree-c0fe02c67b3d@spud>
References: <20240517123909.680686-1-leon@georgemail.de>
	<7471f037-f396-4924-8c8d-e704507de361@lunn.ch>
	<20240517-unscrew-handsfree-c0fe02c67b3d@spud>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi :-)

On Fri, 17 May 2024 17:13:18 +0100
Conor Dooley <conor@kernel.org> 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