Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b37c22a2-14e2-4d8e-e68b-bd26e4ab4072@gmail.com>
Date:   Wed, 21 Sep 2022 13:57:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101
 Thunderbird/96.0
Subject: Re: [PATCH] dt-bindings: nvmem: u-boot, env: add Broadcom's variant
 binding
To:     Rob Herring <robh@kernel.org>,
        Joel Peshkin <joel.peshkin@broadcom.com>
Cc:     =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Tom Rini <trini@konsulko.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        "u-boot@lists.denx.de" <u-boot@lists.denx.de>,
        Broadcom Kernel List <bcm-kernel-feedback-list@broadcom.com>,
        linux-kernel@vger.kernel.org,
        William Zhang <william.zhang@broadcom.com>
References: <20220406152515.31316-1-zajec5@gmail.com>
 <CAN3=V2vOVLc95ZYBUDo8J7ast4UQMnZm4uYmX63LpcJdZWnmNQ@mail.gmail.com>
 <Yk8qnxqXK7WZvXrS@robh.at.kernel.org>
From:   =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>
In-Reply-To: <Yk8qnxqXK7WZvXrS@robh.at.kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.