diff options
author | Michael Walle <michael@walle.cc> | 2023-04-04 18:21:21 +0100 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2023-04-05 19:41:11 +0200 |
commit | 266570f496b90dea8fda893c2cf7c28d63ae2bd9 (patch) | |
tree | 8f249c056530d430fec83e63a850bdbdb483d0bb /net/socket.c | |
parent | 2f555f58f5ce33b201235e104823662d5573c4a5 (diff) | |
download | linux-stable-266570f496b90dea8fda893c2cf7c28d63ae2bd9.tar.gz linux-stable-266570f496b90dea8fda893c2cf7c28d63ae2bd9.tar.bz2 linux-stable-266570f496b90dea8fda893c2cf7c28d63ae2bd9.zip |
nvmem: core: introduce NVMEM layouts
NVMEM layouts are used to generate NVMEM cells during runtime. Think of
an EEPROM with a well-defined conent. For now, the content can be
described by a device tree or a board file. But this only works if the
offsets and lengths are static and don't change. One could also argue
that putting the layout of the EEPROM in the device tree is the wrong
place. Instead, the device tree should just have a specific compatible
string.
Right now there are two use cases:
(1) The NVMEM cell needs special processing. E.g. if it only specifies
a base MAC address offset and you need to add an offset, or it
needs to parse a MAC from ASCII format or some proprietary format.
(Post processing of cells is added in a later commit).
(2) u-boot environment parsing. The cells don't have a particular
offset but it needs parsing the content to determine the offsets
and length.
Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20230404172148.82422-14-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net/socket.c')
0 files changed, 0 insertions, 0 deletions