Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp283509pxm; Tue, 22 Feb 2022 10:31:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJz1nmQirMvVaLBvVXz+jCFL3N3K7Ai8T1Jye0RqWbcbflQvNUjVz8wZxtVQkn8QpMVfGM84 X-Received: by 2002:a17:906:22cf:b0:6cd:2c02:45fc with SMTP id q15-20020a17090622cf00b006cd2c0245fcmr20568403eja.295.1645554704275; Tue, 22 Feb 2022 10:31:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645554704; cv=none; d=google.com; s=arc-20160816; b=BJPgdzV6jBvCBkU7/or4JYG2wasCcHJHkIRMXh1GMp9hKWoMlyxBgywJVQeg8lRFZm ny+G3Lf/F6UlnkMJL+1Lgd01XG3J0LixP6CCV2op6p1R5eJqs5tJdT8YDD14/f8JM+2V z5StncPqvj+jbFaxfPIQpz3/Mg0ltANfZ+tQxT5mUgcaRJowtP5AVZjEYH5YtskY4q76 eES91JTwhQSfjO9DobiboQTzRhpVolXWAKYCg0Ricck41uW3q4qwgJV5PdvMObUiYCRv sRtrhhdMBV30khg+xwTvdKsoapo1lhhZDm4jQBVEv2qH5Dge02llBoSWe0VeJMjtgs+t 1UtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=LeuBg4dOuh5JH3e3jvl1u82+i4KgmUWsl9hqSaPqdVs=; b=D+pXRip99B4j6y+FiPHR3OY+ucy8QCmgMGxGpV8urHHta/PUvlGtCZwXlUY9tv3XO7 GbkCJdcigWUm6cYZglYyVtGzFV2Ohf2QUS3Fn2lqXYNb867Pg07XIApnuV5CgUW8vhKR Ykw4I0NRJgexdMkxlQ5T9P4d6hQZAktHzoDuv3ZODY+Ul/NXdyr/OfhCETEKOxsbXwWI qjalffy8QRTF8oY3H4VjQ6MYK1iBGT9xtPScIGU3/LUhFK5LatfxkHR+iYr3mubFEiXx l5vhQV2Xg8WLKX5R/GmPWolsw/Mc6dcXd1LFnhzg6YcRy9soG5ERTtkstsZDBqB3HpF2 VNWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eGutWihD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j3si1179652eda.384.2022.02.22.10.31.17; Tue, 22 Feb 2022 10:31:44 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eGutWihD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S234862AbiBVSZ2 (ORCPT + 99 others); Tue, 22 Feb 2022 13:25:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230325AbiBVSZ1 (ORCPT ); Tue, 22 Feb 2022 13:25:27 -0500 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8B45EAC8C; Tue, 22 Feb 2022 10:25:01 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id q17so39235250edd.4; Tue, 22 Feb 2022 10:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=LeuBg4dOuh5JH3e3jvl1u82+i4KgmUWsl9hqSaPqdVs=; b=eGutWihD+Ld7dXfTSK4HpFHNWgyC915Sn/OxmxZwaO0MadBFi0DfhUYgPGrEkZvPLi NfmXyZ7DlkyHThFli/HDpOLQZq8nF/d+1q0DuBUxBhPBFadfAOT3pQegs8S0VYRuRZ3S Npin/21oE2k8gERsUAS7pZ3Dg9af+GQR+AU1eHtvOuS3Rl/99JVXXnMrFH3z9geabAff nVE2M1sL96hghm9nc+alhJAVaVbZTxY5TfSwBZ0MC4LoY1aiTbt5PA9u5hEKjWoUSGPR TvGfUNCEorD5JXlybq9gBpGieiEVQG/DvGXz2UncuMuYuZPcqNyE/xYERQMxSK1hLnsl bOiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=LeuBg4dOuh5JH3e3jvl1u82+i4KgmUWsl9hqSaPqdVs=; b=EPzXsNUzA8cxbmGb0UwUdgyO4Nfn9XzNRPmAub4sAsgPuG1qMjsMw/jWfbNTym/0Nt yoSW05V/rMxyFW9mQvpFULqFb+ZYH0B+HuvooF2NrRVJ3BeoS+sZu46UbWmZ2bdQ97KG S7jFsfOHV/LzJWmd4o955CWDnOkhk6tf5ReMyhlime5JwIKhilsnFzarjiUGrvmESZ3e 4A9pwDAHb4BlpMuS76yUzhFN+7VV8x41RjXZSvmWNJQLCU4RxYOmS6zu66BuD/dsqRY6 Ral21b90hsHfh+eJ/Bmb/cluhBswAm2gsqvrrNeMNSTJPYhHNnq6JJ0JNBpQmGCHF1bq 2c7A== X-Gm-Message-State: AOAM533XnmBbSjVxBc2hhLxKZ59vLJExVclU0ieEguwUAYGIeY5PCJT7 arr15ZSK8QrRaU/FFwVbTi8= X-Received: by 2002:a05:6402:f04:b0:410:f0a5:5b02 with SMTP id i4-20020a0564020f0400b00410f0a55b02mr28509835eda.209.1645554300299; Tue, 22 Feb 2022 10:25:00 -0800 (PST) Received: from Ansuel-xps.localdomain (93-42-71-246.ip85.fastwebnet.it. [93.42.71.246]) by smtp.gmail.com with ESMTPSA id j19sm6624244ejo.202.2022.02.22.10.24.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Feb 2022 10:24:59 -0800 (PST) Date: Tue, 22 Feb 2022 19:24:58 +0100 From: Ansuel Smith To: Rob Herring Cc: Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC RFT PATCH v2 1/2] dt-bindings: mtd: partitions: Document new partition-dynamic nodes Message-ID: References: <20220220173905.14165-1-ansuelsmth@gmail.com> <20220220173905.14165-2-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 22, 2022 at 12:18:56PM -0600, Rob Herring wrote: > On Sun, Feb 20, 2022 at 06:39:04PM +0100, Ansuel Smith wrote: > > Document new partition-dynamic nodes 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. > > > > With these special partitions, only the label is required as the parser > > will provide reg and offset of the mtd. NVMEM will use the data from the > > parser and provide the NVMEM cells declared in the DTS, "connecting" the > > dynamic partition with a static declaration of cells in them. > > > > Signed-off-by: Ansuel Smith > > --- > > .../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++ > > 1 file changed, 54 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml > > > > diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml > > new file mode 100644 > > index 000000000000..945128e754ac > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml > > @@ -0,0 +1,54 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mtd/partitions/partition-dynamic.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Dynamic Partition > > + > > +description: | > > + This binding describes a single flash partition that is dynamically allocated > > + by a dedicated parser that is not a fixed-partition parser. To declare a > > + partition the label is required. This can be used to give a dynamic partition > > + an OF node so that subsystems like NVMEM can work and provide NVMEM Cells to > > 'subsystems like NVMEM' is a Linux detail that shouldn't be in bindings. > > > + the system. An example is declaring the partition label and all the NVMEM > > + cells in it. The parser will detect the correct reg and offset and the NVMEM > > + will register the cells in it based on the data extracted by the parser. > > + > > +maintainers: > > + - Ansuel Smith > > + > > +properties: > > + label: > > + description: The label / name for the partition assigned by the parser at > > + runtime. This is needed for sybsystem like NVMEM to define cells and > > + register with this OF node. > > 'label' is generally for human consumption and should be opaque to the > OS (or at least the kernel). Perhaps node name should be used like > RafaƂ is doing for nvmem[1]. That appears to be the same problem at the > next level down. > > Rob > > [1] https://lore.kernel.org/all/20220218070729.3256-1-zajec5@gmail.com/ Ok will add support for node name. Problem is that properties is mandatory in Documentation and can't be None... so how should I handle this? Keep label but set it as not required? -- Ansuel