[PATCH v9 4/8] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device

[Manikandan.M at microchip.com]

Hi Michael,

On 11/2/26 1:25 PM, Michael Walle wrote:
> 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.
Agreed, I missed the sysfs user, I'll keep registering the device 
without a "jedec,sfdp" node in v10, as in v9.

The case Sashiko reported comes from the of_node fallback in 
nvmem_register() rather than from this patch, a flag(new field) in 
struct nvmem_config to skip that fallback would fix, I'll leave it out 
of this series.
> 
>> 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


-- 
Thanks and Regards,
Manikandan M.