Hello, Here is a series bringing support for an NVMEM layout parser. The table that will get processed has been standardized by the ONIE project [1] and its content is highly dependent on the manufacturer choices. There is a dedicated process to read it, but in no case we can define the nvmem cells location/length statically in the DT like other NVMEM cells. Instead, we need what the "layout" abstraction proposed here [2] brings: a dynamic way to find and export NVMEM cells. So this series is actually dependent on [2] and cannot be merged without it. The mvpp2 patch is an example of use which was useful to me during my test runs, so I figured out it might make sense to upstream it. I am not 100% convinced this is the right way so reviews there are welcome. [1] https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html [2] https://lore.kernel.org/linux-arm-kernel/20220921115813.208ff789@xps-13/T/ Cheers, Miquèl Miquel Raynal (5): dt-bindings: vendor-prefixes: Add ONIE dt-bindings: nvmem: add YAML schema for the ONIE tlv layout nvmem: layouts: Add ONIE tlv layout driver MAINTAINERS: Add myself as ONIE tlv NVMEM layout maintainer net: mvpp2: Consider NVMEM cells as possible MAC address source .../nvmem/layouts/onie,tlv-layout.yaml | 96 +++++++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 + drivers/nvmem/layouts/Kconfig | 9 + drivers/nvmem/layouts/Makefile | 1 + drivers/nvmem/layouts/onie-tlv.c | 240 ++++++++++++++++++ 7 files changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml create mode 100644 drivers/nvmem/layouts/onie-tlv.c -- 2.34.1
