Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1977119pxb; Sat, 22 Jan 2022 11:59:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJzx3VYz46etORIjeDKjIPi4Wwcl1sC35OmWN0BUTrfhOOY1ADhEKVKKpah9xrBp4yR/1y/4 X-Received: by 2002:a17:903:234e:b0:14b:f05:a53c with SMTP id c14-20020a170903234e00b0014b0f05a53cmr8500922plh.50.1642881547218; Sat, 22 Jan 2022 11:59:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642881547; cv=none; d=google.com; s=arc-20160816; b=gERNWUL8zF3yC5nVW0YOhwvt6083HOUyfBgvYMz4hl8kKMEZVhjhDVt/wgGyPfgPO0 wvwlCNEmnBLGX/173sVHVd+/bX6h+cgGcpGeVpIpefZUszo7pnRsVX/onvHniR5VrgcE aZ3gI5mu+/NjRqRUqY4iIauESxoiWPCrigCdFLueDbGc/dYP1IdCfOPgHq1Co/aJnh5W M0/posLVs0FDsnWa5a2FfNLz/4QMin6t02hazht4+wp4j5L8FiOacLzAlbJ+Fnab1wsf RtmhhlEwyix/3SFCTZdws3FovhfB6ZTSo7Yo0dT42YEiQxcOngWfcSlhrGfTeFiK5dhx +12Q== 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-disposition:mime-version :references:subject:cc:to:from:date:message-id:dkim-signature; bh=mhD6j/BV1CQACD/fChlzg0PMSKEU6I+hrwON9lOSoaA=; b=NS0HY5P5JgyKo8/f9ulTLXjQWAXR1Vq7x7hRrAUGeYSuN1LwjnHgtrNz1L6xtB9Mdt gxnLdKPy/kqx1SF9Uly+x6kmnhkPHgJ62wUUz0cI4aQA1w4bArru9dRAhcsapcyn11aN jWGHk2uE3p6K6/KGDmH6Bse4Dl8cHyg5LhCV2LMHPpfZhxHF27VxNui4wky344MCbFHT EH0fHIsRGNdGFX8D/DSRWTI25K1GUHJYACRjuHP3wd/1aKwb9BZEdVLvI9tg4L+WItHn 2KJLjHUJeRtMq1c9JidVV+j5OTP6L7riuE8G2Ppae3WPskRa/Cct000yButG0H0AQ4ju g9mg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=g50zwZ2T; 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 s10si9847608pgr.721.2022.01.22.11.58.55; Sat, 22 Jan 2022 11:59:07 -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=g50zwZ2T; 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 S230345AbiAVAaA (ORCPT + 99 others); Fri, 21 Jan 2022 19:30:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230010AbiAVA37 (ORCPT ); Fri, 21 Jan 2022 19:29:59 -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 B8277C06173B; Fri, 21 Jan 2022 16:29:58 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id f21so45409458eds.11; Fri, 21 Jan 2022 16:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:from:to:cc:subject:references:mime-version :content-disposition:in-reply-to; bh=mhD6j/BV1CQACD/fChlzg0PMSKEU6I+hrwON9lOSoaA=; b=g50zwZ2TmnjXt74lE/EXTPRa3IITbq/SiEjWV1PgYyj5+i6Wq1FQW2/R0Jwe1K0iFN zB1eCkLt4GFHtD/M3qfnj+ue8IS/rUa9VpD8a2PQlhh2DPeiFt41Gmq5HY432AIo6W8S fL0B9KIdr1uguqx1eKi9XHlE+Q/jQVHHR5ey14DqXDHkx368Dr1BpjL9N9ZCQLzmMD5K P2hpb7/PvIGYxdv4qAchBOFbPbd4qH51JMVQQJ9oKzjVRySskUWKdF8Mg17LqtNJHGIp stGLHuYyU8/wmeIK12G2tDWuU7TCbT71+dSwb3zVEcJOgBXlUrdYv9b6ckPbLj3mDDgJ O5XQ== 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:from:to:cc:subject:references :mime-version:content-disposition:in-reply-to; bh=mhD6j/BV1CQACD/fChlzg0PMSKEU6I+hrwON9lOSoaA=; b=i6Z90d7IiFqlkZKk9ujDDgYLVDF5cTdPBwZyoQ4ybKICzk7Z36nfhlcwPMlQY4Jz/g 4EcrqhSuGoMiODVhZ/UxEswCam1yczMzLZIHEw0DwmkLNsAKavIrgI5v7PmwHDDEjHbZ nB4plZKUpsdHsV1psQaIJx+UueBkeXrO8daGBdttp5Ycgmbzr4NjOdlNd4V4iGkhP3df 5tXZlW8GRbiN/ZwJrSYYtuxDMpyDlsR0vrV7+n7/nxYLPr1RXQ3L9Zx2W8RgrLzkndEc 2EOUJoQx2vzt7epdzdRlpBVZqU87P+NCkVj9SG6YV3J+7yc2AC03IsoVAFIkxXJDEpzW h9Yg== X-Gm-Message-State: AOAM531sZUIVaxYDxZ6ZkwwWDvc7ND+Oc+5mFjncFpLJa5+p/KqW6kRe qrTENB4H4o/UyC4rbkgFt1RYG7zjbCQ= X-Received: by 2002:a05:6402:4490:: with SMTP id er16mr6153231edb.203.1642811397071; Fri, 21 Jan 2022 16:29:57 -0800 (PST) Received: from Ansuel-xps. (93-42-71-246.ip85.fastwebnet.it. [93.42.71.246]) by smtp.gmail.com with ESMTPSA id r15sm2426733ejz.72.2022.01.21.16.29.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jan 2022 16:29:56 -0800 (PST) Message-ID: <61eb5004.1c69fb81.43dc1.b0f4@mx.google.com> X-Google-Original-Message-ID: Date: Sat, 22 Jan 2022 01:29:54 +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 PATCH 1/2] dt-bindings: mtd: partitions: Document new dynamic-partitions node References: <20220120202615.28076-1-ansuelsmth@gmail.com> <20220120202615.28076-2-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 20, 2022 at 07:49:26PM -0600, Rob Herring wrote: > On Thu, Jan 20, 2022 at 09:26:14PM +0100, 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. > > So you have some discoverable way to find all the partitions and the > nvmem cells are at an unknown (to the DT) location, but still need to be > described in DT? > Example: smem partition layout is saved in the bootloader and static. To know the layout just boot the device and extract it. Aside from this the naming convention is ""standard"" (example the standard nvmem location for this is named 0:art) What needs to be described in the DT is the cell offset and the partition name (the location) NVMEM doesn't support this and honestly I can't think of a simple and direct way to solve this. Considering partition in this case are just filled at runtime and they doesn't change (or at worst the partition offset change but NEVER the name) it seems a good way to fix this by describing a nvmem cells partition name and assign a of node to the runtime filled partition. > > 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 > > Some information in DT and some on the cmdline seems broken to me. Pick > one or the other. > Converting a system from cmdline to fixedpartition is problematic if the cmdline is dynamic. Example some system have dual partition and are handled by editing the cmdline partition description. In this cmdline tho the nvmem cell of our interest doesn't change and we can use this new implemenation to add support for nvmem cells. So really there are some case where nvmem won't work and it's not possible to provide a correct configuration for nvmem to work correctly. Is it that bad to have information in the DT about nvmem cells for a partition named with a particular label that won't change. > > + 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 > > This is useless. This tells me nothing about the what's in the > 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>; > > + }; > > + }; > > + }; > > -- > > 2.33.1 > > > > -- Ansuel