Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7568839rdb; Wed, 3 Jan 2024 23:59:00 -0800 (PST) X-Google-Smtp-Source: AGHT+IEZMORxHYDX5rrc2VZvphp6zdHyPxCVsmE284bZm89l//duK1D4+rSVytGhDLGKgS9wmIhH X-Received: by 2002:a05:6902:1022:b0:dbd:9887:e185 with SMTP id x2-20020a056902102200b00dbd9887e185mr197359ybt.90.1704355140393; Wed, 03 Jan 2024 23:59:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704355140; cv=none; d=google.com; s=arc-20160816; b=gbaHvyCKh0f83oFuyxl4lAhOjb7OsJk5i9emqEiGy9/MoJ8+0SR1Ol9UzBJ2zjx54M hzq719SSB/GAe1l8YJ6yxG4+pUmXRYVvhqmuEro0Pdr94RiD/i1zbSvKZXPshf0gqEh9 CrByKiZdUfK+RyCyxdV9dw3/4A65jtoCS+Vu7bnzlyyzQ3ZqG8CTcSgxGwBoXxb7ukgJ Y+6hPQq4mYoMifaKLLDNFkXk+s46pu2UNnt7bgaPFa3Y4BLbT3yhocxNRW3UhE1yMAJ6 JpEhgQiy+MiIp1V62jDujWXcGH+5N+CbLlnrb7Xn8FzGlOg8EtvSN7JYLCeMyj9Mjxgn g8tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:organization:references :in-reply-to:message-id:subject:cc:to:from:date:dkim-signature; bh=7tDgF8jmLlYnxlNyI3TgVBeZTXRFDyykxfhy3VnRuqc=; fh=Y9slkqVC91i7cRUvEn/I6bCtZ0lkBz1X2b1Z2pBmPYU=; b=tC0aKyQtnnK5URk/12GsrcWHiKdzLlElI2chwjtahw5KQv2OgPASs46z2UbRj+lZlQ Nxx0j1ldXqiNJH9sDvRAS2VUSFOxrmGu8cMhn6RTerJtSnczQtBOvl0T3qTVFioTFNq7 7qD2wNw16BR0QHqm15+2eQTraJfQ/YDSUxm27lgOg09qaZsE1zyi8rQPtZsqeEyjF7eT hykwO9+lTP3lCdw6uqZExtvRkswQfPomVQAOx5jhmDVvBB9m3oI2dpsbG8RxJoV9gQH+ pvs5akGvE8G/Z1I8DJ6RW2WB1ulEkg//Zn5kuKTVC5N//luWZcGzD0PA0KgtrNkMafrD mNSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b="WjHkc//S"; spf=pass (google.com: domain of linux-kernel+bounces-16344-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16344-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id v24-20020a05622a189800b0042962fbc5a1si363397qtc.266.2024.01.03.23.59.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 23:59:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16344-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b="WjHkc//S"; spf=pass (google.com: domain of linux-kernel+bounces-16344-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16344-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 153FA1C212E2 for ; Thu, 4 Jan 2024 07:59:00 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 31E66200AE; Thu, 4 Jan 2024 07:58:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="WjHkc//S" X-Original-To: linux-kernel@vger.kernel.org Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB191200A0; Thu, 4 Jan 2024 07:58:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 42225FF80A; Thu, 4 Jan 2024 07:58:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1704355121; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7tDgF8jmLlYnxlNyI3TgVBeZTXRFDyykxfhy3VnRuqc=; b=WjHkc//SMCn9WSqtxGYRZEWtGnibX5AGg6J5U2qcFSDINWfx1hGmp6q8+7nOrL9VqZQBlI 3P9bKP4usCn5p/pu34lVn1nqKcPI0Vhr4ZYBUW3gHW55natIxMAjFgj+wE6WGGee3JVL0N fa6Qgh2pM6NeJjbsc8VaiLjWvJ4zf1+KzpO+gmYlH4t6pmwswo6QazEjHD4dTl3lzVGjbZ FLdKjgjv71ASWY2DG/E3KQVVI0m55hKHum7MdnLoiLIaIYyHQwF53iY2pXZ8/N38cih49e x/24R4u+6d0hapbAM2sGRhHZOY9zp3THYJMVOblYLJyba70l73XJj9RBGCdv0Q== Date: Thu, 4 Jan 2024 08:58:39 +0100 From: Miquel Raynal To: Rob Herring Cc: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Srinivas Kandagatla , Krzysztof Kozlowski , Conor Dooley , Greg Kroah-Hartman , Michael Walle , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, u-boot@lists.denx.de, =?UTF-8?B?UmFmYcWC?= =?UTF-8?B?IE1pxYJlY2tp?= Subject: Re: [PATCH V3 1/6] dt-bindings: nvmem: layouts: add U-Boot environment variables layout Message-ID: <20240104085839.5624c354@xps-13> In-Reply-To: <20240104001129.GA2045237-robh@kernel.org> References: <20231221173421.13737-1-zajec5@gmail.com> <20240104001129.GA2045237-robh@kernel.org> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com 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=C5=82 Mi=C5=82ecki wrote: > > From: Rafa=C5=82 Mi=C5=82ecki > >=20 > > 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. > >=20 > > 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. >=20 > I don't understand the issue. From a DT perspective, there isn't. A=20 > partition is not a device, but is describing the layout of storage=20 > already. Actually I think what Rafa=C5=82 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=C3=A8l