linux-kernel - [PATCH v3 0/6] Bindings for NVMEM layouts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

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