Add NVMEM support #96379
Add NVMEM support #96379
Conversation
pdgendt
force-pushed
the
nvmem
branch
2 times, most recently
from
3950927 to
4536d4e
Compare
|
@pdgendt this is a nice addition. Can it be extended to other backends (e.g. fuses, bbram) ? IMHO it should be straightforward to add a settings backend for this (e.g. store/retrieve items under "nvmem/xxx"). |
That's the idea, in
Sure, maybe. Outside of the scope of this PR though. |
pdgendt
force-pushed
the
nvmem
branch
2 times, most recently
from
91b7c21 to
1ae57e1
Compare
|
Removed the draft state to get some early feedback before adding more documentation bits. |
decsny
left a comment
decsny
left a comment
There was a problem hiding this comment.
please review linux binding https://www.kernel.org/doc/Documentation/devicetree/bindings/nvmem/ , note also the layouts folder
pdgendt
force-pushed
the
nvmem
branch
2 times, most recently
from
aeee230 to
c1a5bc6
Compare
henrikbrixandersen
left a comment
henrikbrixandersen
left a comment
There was a problem hiding this comment.
I like it! Simple, yet extensible and a good level of abstraction. A few comments below:
| * | ||
| * @kconfig_dep{CONFIG_NVMEM} | ||
| * | ||
| * @return 0 on success, negative errno code on failure. |
There was a problem hiding this comment.
some of these use @return some use @retval, I vaugley remember that @retval needs multiple lines one per value, unsure on @return or if one should be used over the other
There was a problem hiding this comment.
Had one (wrong) use of @retval, updated, thanks!
Adds property nvmem-cells for referencing a node that stores some configuration information. A typical use case is the reading of MAC address from an EEPROM device. Signed-off-by: Andriy Gelman <[email protected]> Signed-off-by: Pieter De Gendt <[email protected]>
Add a devicetree binding to represent a fixed layout in an NVMEM provider. Signed-off-by: Pieter De Gendt <[email protected]>
This commit adds the NVMEM subsystem with a basic implementation for use with EEPROM devices. Signed-off-by: Pieter De Gendt <[email protected]>
Add basic testing to validate the API of the NVMEM subsystem. Add testing with an EEPROM backend. Signed-off-by: Pieter De Gendt <[email protected]>
Add test cases tot the devicetree API testsuite for NVMEM macros. Signed-off-by: Pieter De Gendt <[email protected]>
Introduce a page for the Non-Volatile Memory subsystem with a reference to the doxygen API. Signed-off-by: Pieter De Gendt <[email protected]>
Add an entry to the API and options section for the Non-Volatile Memory subsystem. Signed-off-by: Pieter De Gendt <[email protected]>
Create a section for the newly maintained NVMEM area. Signed-off-by: Pieter De Gendt <[email protected]>
|
Can this be used with SoC Flash, external NOR Flash? |
|
Current implementation in this PR only supports EEPROMs as NVMEM providers, but this can very easily be extended in the future. |
I guess it can, especially for read-only cells. The tricky bit would probably be writing, as it could require additional erase logic. |
|
nice stuff, i have seen this on arch wg agenda last week, are there some minutes somewhere with the outcome? |
mbolivar
left a comment
mbolivar
left a comment
There was a problem hiding this comment.
Binding looks like a good start, no need to boil the ocean and support everything out of the box IMO.
Not sure if notes were taken, I presented the idea and what it is trying to solve (the MAC address logic in network drivers for me), feedback was very positive overall, as far as I can remember. |
|
Architecture WG meeting, 2025-09-30:
|
|
My apologies, just realised I never got around to cleanup my notes from the meeting and actually post them. |
12 participants
Introduce the NVMEM subsystem. Inspired from linux this subsystem allows to read and write data to Non-Volatile memory, for example to store a MAC address or SoC/Device specific data.
It comes with support for EEPROM devices. The device API backend is determined at runtime using
DEVICE_API_IS.See #96598 for an example use case.
Derived from #74835