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

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: <87o6yev8ol.fsf@bootlin.com>
Date: Thu, 06 Mar 2025 09:56:42 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: "Michael Walle" <mwalle@...nel.org>
Cc: <Manikandan.M@...rochip.com>,  <robh@...nel.org>,  <krzk+dt@...nel.org>,
  <conor+dt@...nel.org>,  <Nicolas.Ferre@...rochip.com>,
  <alexandre.belloni@...tlin.com>,  <claudiu.beznea@...on.dev>,
  <tudor.ambarus@...aro.org>,  <pratyush@...nel.org>,  <richard@....at>,
  <vigneshr@...com>,  <devicetree@...r.kernel.org>,
  <linux-arm-kernel@...ts.infradead.org>,  <linux-kernel@...r.kernel.org>,
  <linux-mtd@...ts.infradead.org>,  <Varshini.Rajendran@...rochip.com>
Subject: Re: [PATCH 1/2] mtd: spi-nor: sst: register SFDP region into NVMEM
 framework to read MAC Address


>> >> I don't think it makes sense to have this one-off in a particular
>> >> driver. If at all, this should be handled in the core. Sorry, but
>> >> this really looks like an ugly hack.
>> >> 
>> >
>> > Because the EUI identifier within the SFDP is unique to the 
>> > SST26VF064BEUI flash, I opted to handle it here rather than in the core.
>> >
>> > Also here the MAC address data resides within the 0x260-0x26F range, I 
>> > will resize the nvmem_config.size to 0x10 instead of registering the 
>> > full SFDP region as NVMEM.
>>
>> Open question to all parties in this thread: how do we give an offset in
>> the device tree that is relative to the sfdp region and not the data
>> region? I believe we care not to mix these areas while describing.
>
> You don't do it, because there is not even a relative offset that is
> fixed. There should be a pointer to the vendor table inside the SFDP
> structure. Thus, you need to properly parse it.

If there is nothing static and the location can be derived by reading
the chip tables, I'd suggest to offload this out of the spi-nor core and
instead use some kind of an nvmem layout driver to retrieve the
corresponding region?

> Regarding how to reference it within the device tree, I'd assume
> something along 'compatible = "jedec,sfdp-vendor-table-NNN";' or
> similar. But no static/relative offsets.

I see. We need to invoke our DT binding gurus.

Cheers,
Miquèl