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