[PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM

[Michael Walle]

On Fri Jul 3, 2026 at 12:10 PM CEST, Miquel Raynal wrote:
> On 02/07/2026 at 11:37:23 -05, Rob Herring <robh at kernel.org> wrote:
>
>> On Thu, Jul 02, 2026 at 06:55:15AM +0000, Manikandan.M at microchip.com wrote:
>>> Hi Krzysztof,
>>> 
>>> On 7/2/26 11:46 AM, Krzysztof Kozlowski wrote:
>>> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>> > 
>>> > On Tue, Jun 30, 2026 at 02:54:00PM +0530, Manikandan Muralidharan wrote:
>>> >> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
>>> >> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
>>> > 
>>> > What is SFDP?
>>> > 
>>> SFDP is the Serial Flash Discoverable Parameters -- a JEDEC-standardised
>>> (JESD216) read-only parameter table present in most SPI NOR flashes, the 
>>> table contents provide basic information about the flash. There are 
>>> standard tables which are specified by the JEDEC standard and there are 
>>> vendor tables.
>>
>> Is SFDP present or not discoverable? Or we have a table of discoverable 
>> parameters that itself is not discoverable.
>
> SFDP is almost always there. I don't think there are any non SFDP chips
> manufactured today (?).

Oh i bet there are, and IIRC there were some additions lately. Not
sure if the chip was new though.

> The thing is, even if we don't need to define it
> in DT, we might need to point to it in order to extract eg. a unique ID
> or a MAC address through the NVMEM interface.

Exactly. We can detect whether is a SFDP table or not, by trying to
read its signature using the RDSFDP opcode. But as Miquel pointed
out, that's not what this is about. For the nvmem part being useful,
we have to have some node to point to. At the moment, there are
three different kind of NVMEM devices an spi nor flash can create:
 - partitions
 - factory OTP (i.e. OTP by the flash manufacturer)
 - user OTP (i.e. what an OEM could write to)

Now there's a fourth one: SFDP. It can contain vendor specific
tables, which in the mchp case is used to store a mac address,
which is then used for a NIC.

So we somehow has to organize all of them, thus the sfdp node. A
more complete example would be:

flash at 0 {
	compatible = "jedec,spi-nor";

	partitions {
		compatible = "fixed-partitions";

		partition at 0 {
			compatible = "nvmem-cells";
		};
	};

	otp-1 {
		compatible = "factory-otp";
	};

	otp-2 {
		compatible = "user-otp";
	};

	sfdp {
		compatile = "jedec,sfdp";
	};
};

All being NVMEM devices and expose some kind of data used for
drivers.

HTH
-michael

> SFDP is split into several sub-tables, the first one is mandatory, but
> then there are optional tables which can be discovered dynamically.
>
> Thanks,
> Miquèl