Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3983915pxb; Tue, 25 Jan 2022 00:40:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJyUYKxhAsFrdCXBbp2RAt3e6bJe0zm7r57iS9HGmA+qTs2IsDq23AsO74xtkeFs2+SvoCsH X-Received: by 2002:a17:907:a088:: with SMTP id hu8mr14874211ejc.528.1643100001952; Tue, 25 Jan 2022 00:40:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643100001; cv=none; d=google.com; s=arc-20160816; b=JV45t7MpUTEjDXqfkm86ACB+vmyToNdOZJ2x8M0qOX5QIZ0YsybXt4HiyAxa/txurt XgbqqcM2/s9DfB1swS2HoU8MtM5whHF4XpsTFWkkaE1AYskCLd4bw/UDFe4Suk9zZ4i+ whg7D6/xuBfz8Zzyu6RJvLhjnVZdTXdJJcgOHSE/zRMCNoxUJTL5BDHWU34cpThmR4wJ w2TBIBO/+bUVi/8I2X4lba+PzdpOPj95Rr1uQ/7O+7UuSV5ObKgoh7AxN+4dYU6VTR4J aPCX/8LgF1cE12GztKLoCDnMzrMY3URx/M6sOcNVDhateurmECv1u5nNoqfHFTys9iAZ r7YA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:subject:user-agent:mime-version:date:message-id :dkim-signature; bh=LA2Dp3HJ+xwYPvctInS9E+uCracwEfra/4AQRc/q/i0=; b=mUbf082YhXV6xG5N992btqHmf0u/Rmju74FCrz/cf8GMywtndkT4OaKrhKgxyfqDNW erZdShWqsM72SXsHONRLweZlopxGJRT3aYsFdsQyO5rOvpoCvob+WTamNCZPCB2YDwx9 IZQLtX16oPqcF+w4cSGfKYV/QHjljQ8bQqMKhXuwMFJWPVas6clmwuiLf4np1Uqk6hKP iXFB2xgB/BzYhINjynqGsqaWJS/c8LHxl2Ev4vfWn8zLKmK8B/GSRq0MZJkKGXo2/1wd 3hXUXoJ1WjF44xe8d/NsDYbDQMdiclynIFJhIt3JjHsVxT40ZYVuxfOuOio6L/kuw/T9 6qpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BQOMDC29; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bl4si10357464ejb.250.2022.01.25.00.39.37; Tue, 25 Jan 2022 00:40:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BQOMDC29; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1315642AbiAYCxz (ORCPT + 99 others); Mon, 24 Jan 2022 21:53:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2374233AbiAYAQe (ORCPT ); Mon, 24 Jan 2022 19:16:34 -0500 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A674C038AF4; Mon, 24 Jan 2022 14:02:28 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id t9so2153981lji.12; Mon, 24 Jan 2022 14:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=LA2Dp3HJ+xwYPvctInS9E+uCracwEfra/4AQRc/q/i0=; b=BQOMDC29L23HCp50plS0yQ/NcRC/zrbZlKyPEP7hOhInoYBVaeZUH24Z7ujpjPSKCU 4d5+qyxQ4LX6diCvvQces0kuZXo6fg6qQu3yt0NTGH5DDu43/fuNDgAlvVsOXYzLXdMz vCSGclw87g/DJtyWWcd36nAyxixpmm5bnG47Pd51uQUDkTJAcNmoz4Ih9/JgpuGBbKpQ bFbgHBVgTYJAwrFnAAhhi25ez03beYnFLteivm/JrW3hVnn0bumg7OsK9xtb1QN7wuEw GyY1qY4Ykg8cKArvTqWuwpZfEEFVHUuatG7sJOlp39E74OlqYrFS1yflC+tz1X+usu85 kPMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=LA2Dp3HJ+xwYPvctInS9E+uCracwEfra/4AQRc/q/i0=; b=nGczH3isvQChteDchdxjSnoKQFbi5rCDaAFMKXjoRTRfuwV0NQ3Y5KF6LBQKpJs6Kz Ay+WaeRbRQXPJ1n2bQ5Nc8bWfY7BqXFrhnpJoUWN92MXzjp7CWoCoO4u7gRhzh4igo3B IN2MG8EJTAL5SGMLOR8rUBhB3NRWntnI1AKwhDFaSQs5qwB688JXPiLhswOB5GzQ8IXI Hto4dYQ8y9seNjM8lFjppDuZ5DRXC1+efqBtQjlkSmEZ+HLe21lPTcnZxBfA4KOju3UO RKTjh9ZBPige4e7K/btzZ9HNu7uPeMoHtz5ggluaD18Z8vvWF9OG0OheMZ0qdTq1027C tl+g== X-Gm-Message-State: AOAM530eIXzcYqz06ola3AEQ+aDfDVE+iK7nBPXxVfUFtlUWYZjNUcHT rxDABgjaGdEGLdfS3Qr03S4= X-Received: by 2002:a2e:a4c6:: with SMTP id p6mr6750783ljm.20.1643061746303; Mon, 24 Jan 2022 14:02:26 -0800 (PST) Received: from [192.168.26.149] (ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233]) by smtp.googlemail.com with ESMTPSA id m21sm101912ljh.137.2022.01.24.14.02.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Jan 2022 14:02:25 -0800 (PST) Message-ID: Date: Mon, 24 Jan 2022 23:02:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Thunderbird/96.0 Subject: Re: [RFC PATCH 1/2] dt-bindings: mtd: partitions: Document new dynamic-partitions node To: Ansuel Smith , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Rob Herring , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220120202615.28076-1-ansuelsmth@gmail.com> <20220120202615.28076-2-ansuelsmth@gmail.com> From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= In-Reply-To: <20220120202615.28076-2-ansuelsmth@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20.01.2022 21:26, Ansuel Smith wrote: > Document new dynamic-partitions node used to provide an of node for > partition registred at runtime by parsers. This is required for nvmem > system to declare and detect nvmem-cells. > > Signed-off-by: Ansuel Smith > --- > .../mtd/partitions/dynamic-partitions.yaml | 59 +++++++++++++++++++ > 1 file changed, 59 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml > > diff --git a/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml > new file mode 100644 > index 000000000000..7528e49f2d7e > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml > @@ -0,0 +1,59 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mtd/partitions/dynamic-partitions.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Dynamic partitions > + > +description: | > + This binding can be used on platforms which have partitions registered at > + runtime by parsers or partition table present on the flash. Example are > + partitions declared from smem parser or cmdlinepart. This will create an > + of node for these dynamic partition where systems like Nvmem can get a > + reference to register nvmem-cells. > + > + The partition table should be a node named "dynamic-partitions". > + Partitions are then defined as subnodes. Only the label is required > + as any other data will be taken from the parser. > + > +maintainers: > + - Ansuel Smith > + > +properties: > + compatible: > + const: dynamic-partitions > + > +patternProperties: > + "@[0-9a-f]+$": > + $ref: "partition.yaml#" > + > +additionalProperties: true > + > +examples: > + - | > + partitions { > + compatible = "qcom,smem"; > + #address-cells = <1>; > + #size-cells = <1>; > + }; > + > + dynamic-partitions { > + compatible = "dynamic-partitions"; > + > + art: art { > + label = "0:art"; > + read-only; > + compatible = "nvmem-cells"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + macaddr_art_0: macaddr@0 { > + reg = <0x0 0x6>; > + }; > + > + macaddr_art_6: macaddr@6 { > + reg = <0x6 0x6>; > + }; > + }; > + }; First of all: I fully support such a feature. I need it for Broadom platforms that use "brcm,bcm947xx-cfe-partitions" dynamic partitions. In my case bootloader partition is created dynamically (it doesn't have const offset and size). It contains NVMEM data however that needs to be described in DT. This binding however looks loose and confusing to me. First of all did you really mean to use "qcom,smem"? My first guess is you meant "qcom,smem-part". Secondly can't we have partitions defined just as subnodes of the partitions { ... }; node? I think sth like below would make more sense: partitions { compatible = "qcom,smem-part"; art { label = "0:art"; read-only; compatible = "nvmem-cells"; #address-cells = <1>; #size-cells = <1>; macaddr_art_0: macaddr@0 { reg = <0x0 0x6>; }; macaddr_art_6: macaddr@6 { reg = <0x6 0x6>; }; }; }; Then I could also reuse that for something like: partitions { compatible = "brcm,bcm947xx-cfe-partitions"; partition-0 { compatible = "nvmem-cells"; label = "boot"; #address-cells = <1>; #size-cells = <1>; mac: macaddr@0 { reg = <0x100 0x6>; }; } };