linux-kernel - Re: [PATCH v4 1/5] dt-bindings: nvmem: Introduce the nvmem-layout container

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <166863192845.861669.10779520962009282400.robh@kernel.org>
Date:   Wed, 16 Nov 2022 14:52:09 -0600
From:   Rob Herring <robh@...nel.org>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     linux-kernel@...r.kernel.org, Luka Perkov <luka.perkov@...tura.hr>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Robert Marko <robert.marko@...tura.hr>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Michael Walle <michael@...le.cc>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Subject: Re: [PATCH v4 1/5] dt-bindings: nvmem: Introduce the nvmem-layout
 container


On Mon, 14 Nov 2022 09:56:55 +0100, Miquel Raynal wrote:
> The nvmem devices description works like this:
> 
> * Most cases (EEPROM & co):
> 
> eeprom@x {
> 	 compatible = "<eeprom-compatible>";
> 	 ...
> };
> 
> * MTD case:
> 
> flash@y {
> 	compatible = "<flash-compatible>";
> 	...
> 	otp {
> 		compatible = "user-otp"; /* or "factory-otp" */
> 		...
> 	};
> };
> 
> In the former case, the nvmem device is "eeprom@x", while in the latter
> case the nvmem device is "otp".
> 
> Nvmem devices can produce nvmem cells. The current way to describe nvmem
> cells is to locate them by providing their static byte and bit offset
> and length. These information are stored in subnodes of the nvmem
> device.
> 
> It is now a fact that such description does not fit more advanced use
> cases where the location or the size of the cells may vary. There are
> currently three known situations which require being described
> differently: Kontron's SL28 VPD, ONIE's TLV table and U-Boot's
> environment variables.
> 
> Hence, we need a way to describe the parsers that must be used in order
> to make the dynamic discovery of the nvmem cells. This new description
> must fit both use cases (the generic situation and the MTD case).
> 
> Let's create in both cases a container node named nvmem-layout whose
> content will depend on the parser. Right now nvmem-layout.yaml is
> "empty", but references to additional layout parser bindings will be
> inserted in the near future. The final goal being something that looks
> like:
> 
> * Most cases (EEPROM & co):
> 
> eeprom@x {
> 	compatible = "<eeprom-compatible>";
> 	...
> 	nvmem-layout {
> 		compatible = "<parser-compatible>";
> 		...
> 	};
> };
> 
> * MTD case:
> 
> flash@y {
> 	compatible = "<flash-compatible>";
> 	...
> 	otp {
> 		compatible = "user-otp"; /* or "factory-otp" */
> 		...
> 		nvmem-layout {
> 			compatible = "<parser-compatible>";
> 			...
> 		};
> 	};
> };
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> ---
>  .../bindings/nvmem/layouts/nvmem-layout.yaml  | 30 +++++++++++++++++++
>  .../devicetree/bindings/nvmem/nvmem.yaml      |  7 +++++
>  2 files changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
> 

Reviewed-by: Rob Herring <robh@...nel.org>