linux-kernel - Re: [PATCH v3 0/3] Read MAC address through NVMEM for sama7g5ek

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49a71ee7-b86b-4f44-b7b3-dc0a6433e1c3@microchip.com>
Date: Fri, 28 Jun 2024 14:06:58 +0000
From: <Andrei.Simion@...rochip.com>
To: <arnd@...db.de>, <brgl@...ev.pl>, <robh@...nel.org>, <krzk+dt@...nel.org>,
	<conor+dt@...nel.org>, <Nicolas.Ferre@...rochip.com>,
	<alexandre.belloni@...tlin.com>, <claudiu.beznea@...on.dev>,
	<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 28.06.2024 11:29, Arnd Bergmann wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, Jun 28, 2024, at 10:01, Andrei Simion wrote:
>> This series proposes to add EEPROM support and reading MAC addresses
>> through NVMEM (via Devicetree) for sama7g5ek:
>> - Add in DT bindings document the EEPROM compatibles :
>> "microchip,24aa025e48" and "microchip,24aa025e64"
>> - Update to the driver to support "microchip,24aa025e48" and
>> "microchip,24aa025e64" and adjusting offset for those 24AA025E{48, 64}.
>> - Added the nodes in devicetree for eeproms where are stored EUI-48 MAC,
>> and update gmac nodes to read the MAC via devicetree through NVMEM.
> 
> Can you add an explanation about what this is good for?
> 
> Do you need to work around broken boot loaders that cannot be
> updated and that happen to store the MAC address in the EEPROM,
> or are you proposing this as a generic solution that board
> developers should actually use?
> 
> 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.
> 
>       Arnd


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. 
This patch set is useful for this scenario and also for redundancy (if something related with NET/EEPROM fails in U-Boot).

Best Regards,
Andrei Simion