On Mon Nov 2, 2026 at 6:03 AM CET, Manikandan.M wrote:
>>> +static int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
>>> +{
>>> +     struct device *dev = nor->dev;
>>> +     struct nvmem_config config = { };
>>> +     struct nvmem_device *nvmem;
>>> +     struct device_node *np;
>>> +
>>> +     if (!nor->sfdp)
>>> +             return 0;
>>> +
>>> +     np = of_get_compatible_child(dev_of_node(dev), "jedec,sfdp");
>>> +
>>> +     config.dev = dev;
>>> +     config.of_node = np;
>> 
>> [Severity: High]
>> If the jedec,sfdp child node is missing from the device tree, np will
>> be NULL and assigned to config.of_node. Does this inadvertently trigger the
>> NVMEM core's fallback behavior?
>> 
>> Looking at nvmem_register() in drivers/nvmem/core.c, there is a fallback
>> mechanism for missing nodes:
>> 
>>      if (config->of_node)
>>              nvmem->dev.of_node = of_node_get(config->of_node);
>>      else
>>              nvmem->dev.of_node = of_node_get(config->dev->of_node);
>> 
>> If config.of_node is NULL, the SFDP NVMEM device will incorrectly inherit
>> the SPI NOR flash's main device node.
>> 
>> The NVMEM core then searches for an nvmem-layout child node and will
>> find the layout intended for the main flash memory, attaching all NVMEM
>> cells to the small SFDP NVMEM device and marking the layout node populated.
>> 
>> Later, when the MTD subsystem registers the primary NVMEM device for the
>> actual flash contents, it will skip the layout node because it is already
>> marked populated.
>> 
>> Could any consumer attempting to read an NVMEM cell then be misdirected
>> to the small SFDP NVMEM device's read callback instead of the main flash,
>> resulting in -EINVAL bounds check errors or corrupted data?
>
> Yes, this is a valid issue. With no "jedec,sfdp" node, nvmem_register() 
> falls back to the flash's own node, so the SFDP NVMEM device would claim 
> an "nvmem-layout" meant for the whole flash.
>
> Michael,
> this comes from dropping the "if (!np) return 0;" check in v9. I'll 
> bring it back in v10: without a "jedec,sfdp" node there is nowhere to 
> describe SFDP cells, so the SFDP NVMEM device would have no consumers, 

There is no DT user, yes. But there is then a "sfdpN" file in sysfs
which can be used from user space. And that's what my first remark
was about. Why would that only exist if there is a "jedec,sfdp"
child in the device tree.

> while registering it can take over the flash's layout.
> Do you have any other suggestions?

Probably tell nvmem to not attach it to any of_node?

-michael