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

[Miquel Raynal]

Hello,

robh at kernel.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 at milecki.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