Hello,
robh@xxxxxxxxxx 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@xxxxxxxxxx>
> >
> > 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
