linux-kernel - Re: [PATCH V3 1/6] dt-bindings: nvmem: layouts: add U-Boot environment variables layout

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]

Date: Thu, 4 Jan 2024 08:58:39 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Rob Herring <robh@...nel.org>
Cc: Rafał Miłecki <zajec5@...il.com>, Srinivas Kandagatla
 <srinivas.kandagatla@...aro.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Michael Walle
 <michael@...le.cc>, linux-mtd@...ts.infradead.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, u-boot@...ts.denx.de, Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH V3 1/6] dt-bindings: nvmem: layouts: add U-Boot
 environment variables layout

Hello,

robh@...nel.org wrote on Wed, 3 Jan 2024 17:11:29 -0700:

> On Thu, Dec 21, 2023 at 06:34:16PM +0100, Rafał Miłecki wrote:
> > From: Rafał Miłecki <rafal@...ecki.pl>
> > 
> > U-Boot env data is a way of storing firmware variables. It's a format
> > that can be used of top of various storage devices. Its binding should
> > be an NVMEM layout instead of a standalone device.
> > 
> > This patch adds layout binding which allows using it on top of MTD NVMEM
> > device as well as any other. At the same time it deprecates the old
> > combined binding.
> 
> I don't understand the issue. From a DT perspective, there isn't. A 
> partition is not a device, but is describing the layout of storage 
> already.

Actually I think what Rafał wants to do goes in the right direction but
I also understand from a binding perspective it may be a little
confusing, even more if we consider "NVMEM" a Linux specific concept.

There is today a "u-boot env" NVMEM *device* description which
almost sits at the same level as eg. an eeprom device. We cannot
compare "an eeprom device" and "a u-boot environment" of course. But
that's truly what is currently described.

* Current situation

	Flash device -> U-Boot env layout -> NVMEM cells

* Improved situation

	Any storage device -> NVMEM -> U-Boot env layout -> NVMEM cells

The latter is of course the most relevant description as we expect
storage devices to expose a storage-agnostic interface (NVMEM in
this case) which can then be parsed (by NVMEM layouts) in a storage
agnostic way.

In the current case, the current U-Boot env binding tells people to
declare the env layout on top of a flash device (only). The current
description also expects a partition node which is typical to flash
devices. Whereas what we should have described in the first place is a
layout that applies on any kind of NVMEM device.

Bonus point: We've been working the last couple years on clarifying
bindings, especially with mtd partitions (with the partitions{}
container) and NVMEM layouts (with the nvmem-layout{} container).
The switch proposed in this patch makes use of the latter, of course.

Thanks,
Miquèl