Re: [PATCH 1/2] mtd: spi-nor: sst: register SFDP region into NVMEM framework to read MAC Address

From: "Michael Walle" <mwalle@kernel.org>
To: <Manikandan.M@microchip.com>, <miquel.raynal@bootlin.com>
Cc: robh@kernel.org, conor+dt@kernel.org,
	linux-kernel@vger.kernel.org, vigneshr@ti.com,
	alexandre.belloni@bootlin.com, devicetree@vger.kernel.org,
	richard@nod.at, claudiu.beznea@tuxon.dev,
	tudor.ambarus@linaro.org, linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	Varshini.Rajendran@microchip.com, krzk+dt@kernel.org,
	pratyush@kernel.org
Subject: Re: [PATCH 1/2] mtd: spi-nor: sst: register SFDP region into NVMEM framework to read MAC Address
Date: Thu, 06 Mar 2025 08:41:17 +0100	[thread overview]
Message-ID: <D890I4EPARNO.O0VS9VZUL6IR@kernel.org> (raw)
In-Reply-To: <84b1def7-fba7-4f29-a49b-d117efe26d26@microchip.com>

Hi,

> >> From: Varshini Rajendran <varshini.rajendran@microchip.com>
> >>
> >> EUI identifier and the MAC Address of the Ethernet Interface is stored
> >> after the SFDP table of contents starting at address 0x260 in the
> >> QSPI memory.
> >> Register the entire SFDP region read by the spi-nor (nor->sfdp) into the
> >> NVMEM framework and read the MAC Address when requested using the nvmem
> >> properties in the DT by the net drivers.
> >>
> >> In kernel the Ethernet MAC address relied on U-Boot env variables or
> >> generated a random address, which posed challenges for boards without
> >> on-board EEPROMs or with multiple Ethernet ports.
> >> This change ensures consistent and reliable MAC address retrieval from QSPI,
> >> benefiting boards like the sama5d29 curiosity and sam9x75 curiosity.
> > 
> > Do you mean spi-nor have a programmable area in their SFDP table? Isn't
> > this supposed to be a read-only area written once in factory?
> > 
> The SST26VF064BEUI serial quad flash memory is programmed at the factory 
> with a globally unique address stored in the SFDP vendor
> parameter table and it is permanently write-protected.

Why didn't you mention that this is a vendor table in the commit
message?

Anyway, please write proper support in the core for parsing vendor
tables and exposing them as a nvmem device if needed (and asked to
do so by the driver of course).

-michael