summaryrefslogtreecommitdiffstats
path: root/net/socket.c
diff options
context:
space:
mode:
authorMichael Walle <michael@walle.cc>2023-04-04 18:21:21 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2023-04-05 19:41:11 +0200
commit266570f496b90dea8fda893c2cf7c28d63ae2bd9 (patch)
tree8f249c056530d430fec83e63a850bdbdb483d0bb /net/socket.c
parent2f555f58f5ce33b201235e104823662d5573c4a5 (diff)
downloadlinux-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