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

[<Manikandan.M@microchip.com>]

On 06/03/25 1:11 pm, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 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).
> 

Thank you for your feedback, and my apologies for not mentioning that in 
the commit message. I will ensure that vendor table parsing is supported 
in the core driver going forward to access the MAC information.

To address the Cadence MAC driver's reliance on U-Boot environment 
variables, NVMEM devices, or random address generation if first 2 fails 
, I believe exposing the MAC address via NVMEM in the Device Tree is the 
only viable solution. Since SFDP data cannot be fetched after the probe 
time, this approach ensures reliable MAC address retrieval.

> -michael

-- 
Thanks and Regards,
Manikandan M.