[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <0aa1f738-c02d-49d7-af11-5bf284677e81@app.fastmail.com>
Date: Fri, 28 Jun 2024 16:25:41 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Andrei Simion" <Andrei.Simion@...rochip.com>,
"Bartosz Golaszewski" <brgl@...ev.pl>, "Rob Herring" <robh@...nel.org>,
krzk+dt@...nel.org, "Conor Dooley" <conor+dt@...nel.org>,
"Nicolas Ferre" <Nicolas.Ferre@...rochip.com>,
"Alexandre Belloni" <alexandre.belloni@...tlin.com>,
"Claudiu Beznea" <claudiu.beznea@...on.dev>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Cc: linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 0/3] Read MAC address through NVMEM for sama7g5ek
On Fri, Jun 28, 2024, at 16:06, Andrei.Simion@...rochip.com wrote:
> On 28.06.2024 11:29, Arnd Bergmann wrote:
>>
>> As far as I can tell, even with this logic in place, users
>> are better off just having the boot loader read the EEPROM
>> and storing the MAC address in the in-memory dtb as we do
>> on other platforms.
>
> Our boot chain is ROM BOOT -> AT91Bootstrap -> U-Boot -> Linux Kernel.
> U-Boot is the stage where we set up the MAC address.
> We can skip U-Boot and use the following boot chain ROM BOOT ->
> AT91Boostrap -> Linux Kernel.
Right, I can see how that is useful. Can you add that description
in the patch?
> This patch set is useful for this scenario and also for redundancy (if
> something related with NET/EEPROM fails in U-Boot).
Not sure if redundancy is what we want the boot loader level ;-)
Arnd
Powered by blists - more mailing lists