[PATCH] nvmem: add explicit config option to read OF fixed cells
zajec5 at gmail.com
Tue Feb 21 14:29:48 PST 2023
On 21.02.2023 22:38, Martin Blumenstingl wrote:
> On Tue, Feb 21, 2023 at 3:50 PM Rafał Miłecki <zajec5 at gmail.com> wrote:
>> From: Rafał Miłecki <rafal at milecki.pl>
>> NVMEM subsystem looks for fixed NVMEM cells (specified in DT) by
>> default. This behaviour made sense in early days before adding support
>> for dynamic cells.
>> With every new supported NVMEM device with dynamic cells current
>> behaviour becomes non-optimal. It results in unneeded iterating over DT
>> nodes and may result in false discovery of cells (depending on used DT
> I am not familiar with the recent changes around dynamic cells.
> Is there any discussion/summary that I can read to get up to speed?
Some NVMEM devices don't store specific data at hardcoded offsets. For
such devices we have drivers (to become: layouts) that parse their magic
content. They discover cells and register them and provide matching with
proper DT nodes.
For bindings see:
For example driver see:
For usage see:
> My main thought is: if there are many "fixed OF cells" implementations
> and only a few "dynamic" ones - does it make sense to flip the logic
> and introduce a new "use_dynamic_of_cells" flag instead?
The problem is that there are more cases than just two. We can have:
1. No cells at all
2. Fixed cells in DT
3. Dynamic cells with references in DT
4. Driver specified cells (specified within config)
5. Cells defined in a global table
So we need to reference DT cells explicitly (we can't just confirm /
deny *dynamic* cells).
Another solution would be to have "no_fixed_of_cells" but:
1. Personally I think negation is less clear / easy to follow
2. There may be actually more drivers with no fixed cells.
I think I modified 18 drivers. It seems devm_nvmem_register() is
referenced in 44 places. Few of them may be not actual users but it
still seems to be about equal.
More information about the linux-mtd