linux-kernel - Re: [PATCH] dt-bindings: nvmem: u-boot, env: add Broadcom's variant binding

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] [day] [month] [year] [list]

Message-ID: <b37c22a2-14e2-4d8e-e68b-bd26e4ab4072@gmail.com>
Date:   Wed, 21 Sep 2022 13:57:18 +0200
From:   Rafał Miłecki <zajec5@...il.com>
To:     Rob Herring <robh@...nel.org>,
        Joel Peshkin <joel.peshkin@...adcom.com>
Cc:     Rafał Miłecki <zajec5@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Tom Rini <trini@...sulko.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        "u-boot@...ts.denx.de" <u-boot@...ts.denx.de>,
        Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>,
        linux-kernel@...r.kernel.org,
        William Zhang <william.zhang@...adcom.com>
Subject: Re: [PATCH] dt-bindings: nvmem: u-boot, env: add Broadcom's variant
 binding

On 7.04.2022 20:17, Rob Herring wrote:
> On Thu, Apr 07, 2022 at 04:55:14AM -0700, Joel Peshkin wrote:
>>     The first 32b value is a magic number (endian swapped mnemonic of "uEnv"
>> short for "u-boot environment").   Finding that magic number of a 4K
>> boundary followed by a length and then a u-boot environment with a valid
>> CRC permits a scan of the flash partition to locate the environment without
>> knowing a-priori where it is.
> 
> So it doesn't need to be described in DT? But how does one identify
> whether to scan the flash or not. You wouldn't want to do that one every
> platform. IOW, it's a sufficient discovery mechanism for a custom build,
> but not generic OS.

I can't tell if U-Boot is ever going to handle discovery based on that
binding.

I still find it very practical for operating systems (like Linux).
Consider:

&flash {
	partitions {
		partition-loader {
			compatible = "brcm,u-boot";

			partition-u-boot-env {
				compatible = "brcm,env";

				mac: ethaddr {
				};
			};
		};
	};
};

&enet {
	nvmem-cells = <&mac>;
	nvmem-cell-names = "mac-address";
};

That allows operating system to have:
1. Driver for finding env data subpartitions [1]
2. Independent driver parsing env data structured with Broadcom's format

[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=27bfb201b2c03c8a033b60e5ad80cbf3aaa52b94



If you don't like it, another option could be to use "u-boot,env" and
then make U-Boot env data NVMEM driver detect actual format.



Please let me know if any of above options looks acceptable or if you
can think of another solution.