From patchwork Fri Nov 4 16:38:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miquel Raynal X-Patchwork-Id: 13032354 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9067DC4332F for ; Fri, 4 Nov 2022 16:40:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gCGh4Kzi5nRns1CfM91Dn8DZoriDcNirTXynKt2oPAY=; b=S/FaK/woqnqWMT dTVCGZTBNOQShGSfDV/TkCugeynKnovGuiVd43EH7kxTtyVVziHUo+2Np0uQobg9hngF7oT+k4e0o ImnB5IxNpKSutIMc7nWWoGHZ7Tl46o7la7tqNz0FGhTvAWa6+dH7MYOkBMPn/TdvxxW10KX6uLJHO NTWdfWJ3xrATpkstui/WbBY/60DA0HI28eYR1esCZHoIiDiSApWwjZ/5XPTT2Sv2h82UQoq725CAb f9AJ/TPA1sWq+Ix1WhaJsI9VMGVGgsLquBq3kWK56SQn8VQ7tpW3Www+NIGQWpLPmSQvglzTBTY5z 8LuLQyGpczr34VCq5eFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqzio-004SKU-Fk; Fri, 04 Nov 2022 16:39:10 +0000 Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqziM-004S9b-H8 for linux-arm-kernel@lists.infradead.org; Fri, 04 Nov 2022 16:38:44 +0000 Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 389D9C000D; Fri, 4 Nov 2022 16:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1667579918; 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=O4AM4lnV2gTii8655Tt65FHVrgfOcRYc0nYRGkNgVIU=; b=DqU/oCr8N0GTdjVft/L1DgvUTSld6b0y64b8fQwnjGFy4ty36q1VizpqfgH8oBFVCM9NwR GsrZSdlkvQ2faePej+qjegC+om6gU7PLqW1G6A5KTvMJ0d+/07IopJ7Z1Mh0tPJ89vVGMA Wbi28EL8rEVDAZslj4WTUlWB/DlN16zZmJXKmVJuMOe/avytQvVXqZceK/Z2YzRv9ptz6x 7Jc0YNHtAVbRYKpH1QRJKTYi3tA1EArKHtGFuub6K1I3Rz8eqI6mh7ywdPsT4ztzvlLX9D WnIVmCSbS+wRa1B5gQnPnz1uuMKDcSfjokG7XP8B155cS1WVbZewbkEiB3vKJw== From: Miquel Raynal To: Rob Herring , Krzysztof Kozlowski , devicetree@vger.kernel.org Cc: Srinivas Kandagatla , , Robert Marko , Luka Perkov , Thomas Petazzoni , Michael Walle , , Bartosz Golaszewski , Christian Eggers , Cory Tusar , Miquel Raynal Subject: [PATCH v3 2/6] dt-bindings: nvmem: Introduce the nvmem-layout container Date: Fri, 4 Nov 2022 17:38:29 +0100 Message-Id: <20221104163833.1289857-3-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221104163833.1289857-1-miquel.raynal@bootlin.com> References: <20221104163833.1289857-1-miquel.raynal@bootlin.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221104_093842_875592_3EA48C41 X-CRM114-Status: GOOD ( 16.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The nvmem devices description works like this: * Most cases (EEPROM & co): eeprom@x { compatible = ""; ... }; * MTD case: flash@y { compatible = ""; ... otp { compatible = "user-otp"; /* or "factory-otp" */ ... }; }; In the former case, the nvmem device is "eeprom@x", while in the latter case the nvmem device is "otp". Nvmem devices can produce nvmem cells. The current way to describe nvmem cells is to locate them by providing their static byte and bit offset and length. These information are stored in subnodes of the nvmem device. It is now a fact that such description does not fit more advanced use cases where the location or the size of the cells may vary. There are currently three known situations which require being described differently: Kontron's SL28 VPD, ONIE's TLV table and U-Boot's environment variables. Hence, we need a way to describe the parsers that must be used in order to make the dynamic discovery of the nvmem cells. This new description must fit both use cases (the generic situation and the MTD case). Let's create in both cases a container node named nvmem-layout whose content will depend on the parser. Right now nvmem-layout.yaml is "empty", but references to additional layout parser bindings will be inserted in the near future. The final goal being something that looks like: * Most cases (EEPROM & co): eeprom@x { compatible = ""; ... nvmem-layout { compatible = ""; ... }; }; * MTD case: flash@y { compatible = ""; ... otp { compatible = "user-otp"; /* or "factory-otp" */ ... nvmem-layout { compatible = ""; ... }; }; }; Signed-off-by: Miquel Raynal --- .../bindings/nvmem/layouts/nvmem-layout.yaml | 30 +++++++++++++++++++ .../devicetree/bindings/nvmem/nvmem.yaml | 7 +++++ 2 files changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml new file mode 100644 index 000000000000..ecc7c37cbc1f --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml @@ -0,0 +1,30 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/layouts/nvmem-layout.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVMEM (Non Volatile Memory) layouts + +maintainers: + - Srinivas Kandagatla + - Michael Walle + - Miquel Raynal + +description: | + Most NVMEM layouts are static and thus do not require additional description + besides the bytes/bits offset and length. Other layouts can be less statically + define and might require dynamic reading of the NVMEM device in order to + perform their parsing. The nvmem-layout container is here to describe these. + +properties: + compatible: true + + '#address-cells': false + + '#size-cells': false + +required: + - compatible + +unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index 0455506fc30f..75bb93dda9df 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -39,6 +39,13 @@ properties: when it's driven low (logical '0') to allow writing. maxItems: 1 + nvmem-layout: + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml + description: + Alternative to the statically defined nvmem cells, this + container may reference more advanced (dynamic) layout + parsers. + patternProperties: "@[0-9a-f]+(,[0-7])?$": type: object