[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20221104163833.1289857-1-miquel.raynal@bootlin.com>
Date: Fri, 4 Nov 2022 17:38:27 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
devicetree@...r.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
<linux-kernel@...r.kernel.org>,
Robert Marko <robert.marko@...tura.hr>,
Luka Perkov <luka.perkov@...tura.hr>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Michael Walle <michael@...le.cc>,
<linux-arm-kernel@...ts.infradead.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
Christian Eggers <ceggers@...i.de>,
Cory Tusar <cory.tusar@...1solutions.com>,
Miquel Raynal <miquel.raynal@...tlin.com>
Subject: [PATCH v3 0/6] Bindings for NVMEM layouts
Hello,
A month ago, Michael was sending a new iteration of his series bringing
nvmem layout support. The idea is: we currently can produce nvmem cells
statically defined on top of nvmem devices (which themselves may be MTD
devices sometimes) but in some cases we may need more advanced parsing,
which is possible thanks to the introduction of nvmem layout parsers.
I am not taking over the entire series but I recently tried to make use
of these layouts for the ONIE tlv table layout and Rob (rightfully)
pointed out that the description was messy, because of the mix between
nvmem devices and nvmem parsers. This was known to Michael which
initially argued that it was simpler to handle like that.
So here is a new proposal for the bindings which is described in details
within "dt-bindings: nvmem: Introduce the nvmem-layout container". The
idea to avoid mixing different node contents is to use a container node
when relevant (suggested by Rob) which I named nvmem-layout. This
container will have a compatible that describes the parser (plus
possible additional properties).
Michael, I have a few fixup! patches which apply directly to your former
series in order to support this additional container. I propose we first
settle the bindings (including the two direct use cases as examples) and
once merged, we can move forward and respin both the nvmem series + the
layout drivers.
# Original series (v2) from Michael
Link: https://lore.kernel.org/linux-arm-kernel/20220921115813.208ff789@xps-13/T/#mb97d5376647ff3e686b9c55e3d5e0dc80879e84a
Cheers, Miquèl
Michael Walle (1):
dt-bindings: nvmem: add YAML schema for the sl28 vpd layout
Miquel Raynal (5):
dt-bindings: nvmem: Fix example
dt-bindings: nvmem: Introduce the nvmem-layout container
dt-bindings: eeprom: Inherit from nvmem.yaml
dt-bindings: vendor-prefixes: Add ONIE
dt-bindings: nvmem: add YAML schema for the ONIE tlv layout
.../devicetree/bindings/eeprom/at24.yaml | 5 +-
.../devicetree/bindings/eeprom/at25.yaml | 1 +
.../bindings/eeprom/microchip,93lc46b.yaml | 1 +
.../nvmem/layouts/kontron,sl28-vpd.yaml | 60 +++++++++
.../bindings/nvmem/layouts/nvmem-layout.yaml | 34 ++++++
.../nvmem/layouts/onie,tlv-layout.yaml | 115 ++++++++++++++++++
.../devicetree/bindings/nvmem/nvmem.yaml | 8 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
8 files changed, 225 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
--
2.34.1
Powered by blists - more mailing lists