From: Rob Herring <robh@kernel.org>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Manivannan Sadhasivam <mani@kernel.org>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: mtd: partitions: Document new dynamic-partition nodes
Date: Mon, 6 Jun 2022 08:36:15 -0500 [thread overview]
Message-ID: <20220606133615.GA564610-robh@kernel.org> (raw)
In-Reply-To: <629a91f8.1c69fb81.371aa.1d32@mx.google.com>
On Sat, Jun 04, 2022 at 12:57:58AM +0200, Ansuel Smith wrote:
> On Wed, Jun 01, 2022 at 04:06:55PM -0500, Rob Herring wrote:
> > On Thu, May 19, 2022 at 01:32:57AM +0200, Ansuel Smith wrote:
> > > Document new dynamic-partition 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, the reg / offset is not required.
> > > The label binding is used to match the partition allocated by the
> > > parser at runtime and 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 <ansuelsmth@gmail.com>
> > > ---
> > > .../mtd/partitions/dynamic-partition.yaml | 57 +++++++++++++++++++
> > > .../mtd/partitions/qcom,smem-part.yaml | 4 ++
> > > 2 files changed, 61 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/dynamic-partition.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/mtd/partitions/dynamic-partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partition.yaml
> > > new file mode 100644
> > > index 000000000000..f57d7b9cae7f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partition.yaml
> > > @@ -0,0 +1,57 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/mtd/partitions/dynamic-partition.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.
> > > +
> > > + Each child of the parser partition node is then compared and if a match with
> > > + the provided label is found then the OF node is assigned.
> > > +
> > > + These special partition definition can be used to give a dynamic partition
> > > + an OF node to declare NVMEM cells. 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 <ansuelsmth@gmail.com>
> > > +
> > > +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
> >
> > typo
> >
> > > + register with this OF node.
> > > +
> > > +required:
> > > + - label
> > > +
> > > +additionalProperties: true
> > > +
> > > +examples:
> > > + - |
> > > + flash {
> > > + partitions {
> > > + compatible = "qcom,smem-part";
> > > +
> > > + partition-art {
> > > + compatible = "nvmem-cells";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + label = "0:art";
> > > +
> > > + macaddr_art_0: macaddr@0 {
> > > + reg = <0x0 0x6>;
> > > + };
> > > +
> > > + macaddr_art_6: macaddr@6 {
> > > + reg = <0x6 0x6>;
> > > + };
> >
> > There's a problem with the schema structure for this which is a common
> > problem where we have parent and child nodes with parent defined
> > properties in the child nodes (label in this case). The issue is that
> > there is not a single schema applied to the child node which contains
> > all possible properties sub-node names. This is necessary to check for
> > extra, undocumented properties using unevaluatedProperties. The creation
> > of spi-periphera-props.yaml is an example of how to address this. I
> > suspect that all the partition schemas may need similar restructuring.
> >
> > The nvmem-cells schema may happen to already have 'label', so it happens
> > to work (that and unevaluatedProperties is probably missing in places).
> >
> > Given this schema is really just one property which is already
> > documented for 'partition' nodes, all we really need is to say is if
> > 'reg' is not present, then 'label' is required:
> >
> > if:
> > not:
> > required: [ reg ]
> > then:
> > required: [ label ]
> >
> >
>
> Just to make sure. The correct way to implement this would be drop the
> current dynamic-partition schema and expand the partition.yaml with the
> additional if and the extra stuff in the description.
> Wanted to keep the 2 thing separated but if necessary I will follow this
> path.
Yes. I agree separate would have been nice documentation wise,
but the schema has ended having such a small difference it doesn't
make sense anymore.
Rob
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Manivannan Sadhasivam <mani@kernel.org>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: mtd: partitions: Document new dynamic-partition nodes
Date: Mon, 6 Jun 2022 08:36:15 -0500 [thread overview]
Message-ID: <20220606133615.GA564610-robh@kernel.org> (raw)
In-Reply-To: <629a91f8.1c69fb81.371aa.1d32@mx.google.com>
On Sat, Jun 04, 2022 at 12:57:58AM +0200, Ansuel Smith wrote:
> On Wed, Jun 01, 2022 at 04:06:55PM -0500, Rob Herring wrote:
> > On Thu, May 19, 2022 at 01:32:57AM +0200, Ansuel Smith wrote:
> > > Document new dynamic-partition 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, the reg / offset is not required.
> > > The label binding is used to match the partition allocated by the
> > > parser at runtime and 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 <ansuelsmth@gmail.com>
> > > ---
> > > .../mtd/partitions/dynamic-partition.yaml | 57 +++++++++++++++++++
> > > .../mtd/partitions/qcom,smem-part.yaml | 4 ++
> > > 2 files changed, 61 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/dynamic-partition.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/mtd/partitions/dynamic-partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partition.yaml
> > > new file mode 100644
> > > index 000000000000..f57d7b9cae7f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partition.yaml
> > > @@ -0,0 +1,57 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/mtd/partitions/dynamic-partition.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.
> > > +
> > > + Each child of the parser partition node is then compared and if a match with
> > > + the provided label is found then the OF node is assigned.
> > > +
> > > + These special partition definition can be used to give a dynamic partition
> > > + an OF node to declare NVMEM cells. 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 <ansuelsmth@gmail.com>
> > > +
> > > +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
> >
> > typo
> >
> > > + register with this OF node.
> > > +
> > > +required:
> > > + - label
> > > +
> > > +additionalProperties: true
> > > +
> > > +examples:
> > > + - |
> > > + flash {
> > > + partitions {
> > > + compatible = "qcom,smem-part";
> > > +
> > > + partition-art {
> > > + compatible = "nvmem-cells";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + label = "0:art";
> > > +
> > > + macaddr_art_0: macaddr@0 {
> > > + reg = <0x0 0x6>;
> > > + };
> > > +
> > > + macaddr_art_6: macaddr@6 {
> > > + reg = <0x6 0x6>;
> > > + };
> >
> > There's a problem with the schema structure for this which is a common
> > problem where we have parent and child nodes with parent defined
> > properties in the child nodes (label in this case). The issue is that
> > there is not a single schema applied to the child node which contains
> > all possible properties sub-node names. This is necessary to check for
> > extra, undocumented properties using unevaluatedProperties. The creation
> > of spi-periphera-props.yaml is an example of how to address this. I
> > suspect that all the partition schemas may need similar restructuring.
> >
> > The nvmem-cells schema may happen to already have 'label', so it happens
> > to work (that and unevaluatedProperties is probably missing in places).
> >
> > Given this schema is really just one property which is already
> > documented for 'partition' nodes, all we really need is to say is if
> > 'reg' is not present, then 'label' is required:
> >
> > if:
> > not:
> > required: [ reg ]
> > then:
> > required: [ label ]
> >
> >
>
> Just to make sure. The correct way to implement this would be drop the
> current dynamic-partition schema and expand the partition.yaml with the
> additional if and the extra stuff in the description.
> Wanted to keep the 2 thing separated but if necessary I will follow this
> path.
Yes. I agree separate would have been nice documentation wise,
but the schema has ended having such a small difference it doesn't
make sense anymore.
Rob
next prev parent reply other threads:[~2022-06-06 13:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-18 23:32 [PATCH v4 0/2] Add nvmem support for dynamic partitions Ansuel Smith
2022-05-18 23:32 ` Ansuel Smith
2022-05-18 23:32 ` [PATCH v4 1/2] dt-bindings: mtd: partitions: Document new dynamic-partition nodes Ansuel Smith
2022-05-18 23:32 ` Ansuel Smith
2022-06-01 21:06 ` Rob Herring
2022-06-01 21:06 ` Rob Herring
2022-06-03 22:57 ` Ansuel Smith
2022-06-03 22:57 ` Ansuel Smith
2022-06-06 13:36 ` Rob Herring [this message]
2022-06-06 13:36 ` Rob Herring
2022-05-18 23:32 ` [PATCH v4 2/2] mtd: core: introduce of support for dynamic partitions Ansuel Smith
2022-05-18 23:32 ` Ansuel Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220606133615.GA564610-robh@kernel.org \
--to=robh@kernel.org \
--cc=ansuelsmth@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mani@kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.