All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <tudor.ambarus@linaro.org>,
	Pratyush Yadav <pratyush@kernel.org>,
	Michael Walle <michael@walle.cc>,
	linux-mtd@lists.infradead.org,
	Chris Packham <Chris.Packham@alliedtelesis.co.nz>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v3 02/17] dt-bindings: mtd: Create a file for raw NAND chip properties
Date: Tue, 20 Jun 2023 08:18:43 +0200	[thread overview]
Message-ID: <20230620081843.78187721@xps-13> (raw)
In-Reply-To: <20230619225038.GA1676165-robh@kernel.org>

Hi Rob,

robh@kernel.org wrote on Mon, 19 Jun 2023 16:50:38 -0600:

> On Mon, Jun 19, 2023 at 11:29:01AM +0200, Miquel Raynal wrote:
> > In an effort to constrain as much as we can the existing binding, we
> > want to add "unevaluatedProperties: false" in all the NAND chip
> > descriptions part of NAND controller bindings. But in order to do that
> > properly, we also need to reference a file which contains all the
> > "allowed" properties. Right now this file is nand-chip.yaml but in
> > practice raw NAND controllers may use additional properties in their
> > NAND chip children node. These properties are listed under
> > nand-controller.yaml, which makes the "unevaluatedProperties" checks
> > fail while the description are valid. We need to move these NAND chip
> > related properties into another file, because we do not want to pollute
> > nand-chip.yaml which is also referenced by eg. SPI-NAND devices.
> > 
> > Let's create a raw-nand-chip.yaml file to reference all the properties a
> > raw NAND chip description can contain. The chain of inheritance becomes:
> >   nand-controller.yaml <- raw-nand-chip.yaml
> >   raw-nand-chip.yaml   <- nand-chip.yaml
> >   spi-nand.yaml        <- nand-chip.yaml
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> >  .../bindings/mtd/nand-controller.yaml         |  85 +--------------
> >  .../bindings/mtd/raw-nand-chip.yaml           | 102 ++++++++++++++++++
> >  2 files changed, 104 insertions(+), 83 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > index f70a32d2d9d4..83a4fe4cc29d 100644
> > --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > @@ -16,16 +16,6 @@ description: |
> >    children nodes of the NAND controller. This representation should be
> >    enforced even for simple controllers supporting only one chip.
> >  
> > -  The ECC strength and ECC step size properties define the user
> > -  desires in terms of correction capability of a controller. Together,
> > -  they request the ECC engine to correct {strength} bit errors per
> > -  {size} bytes.
> > -
> > -  The interpretation of these parameters is implementation-defined, so
> > -  not all implementations must support all possible
> > -  combinations. However, implementations are encouraged to further
> > -  specify the value(s) they support.
> > -
> >  properties:
> >    $nodename:
> >      pattern: "^nand-controller(@.*)?"
> > @@ -51,79 +41,8 @@ properties:
> >  
> >  patternProperties:
> >    "^nand@[a-f0-9]$":
> > -    $ref: nand-chip.yaml#
> > -
> > -    properties:
> > -      reg:
> > -        description:
> > -          Contains the chip-select IDs.
> > -
> > -      nand-ecc-placement:
> > -        description:
> > -          Location of the ECC bytes. This location is unknown by default
> > -          but can be explicitly set to "oob", if all ECC bytes are
> > -          known to be stored in the OOB area, or "interleaved" if ECC
> > -          bytes will be interleaved with regular data in the main area.
> > -        $ref: /schemas/types.yaml#/definitions/string
> > -        enum: [ oob, interleaved ]
> > -
> > -      nand-bus-width:
> > -        description:
> > -          Bus width to the NAND chip
> > -        $ref: /schemas/types.yaml#/definitions/uint32
> > -        enum: [8, 16]
> > -        default: 8
> > -
> > -      nand-on-flash-bbt:
> > -        description:
> > -          With this property, the OS will search the device for a Bad
> > -          Block Table (BBT). If not found, it will create one, reserve
> > -          a few blocks at the end of the device to store it and update
> > -          it as the device ages. Otherwise, the out-of-band area of a
> > -          few pages of all the blocks will be scanned at boot time to
> > -          find Bad Block Markers (BBM). These markers will help to
> > -          build a volatile BBT in RAM.
> > -        $ref: /schemas/types.yaml#/definitions/flag
> > -
> > -      nand-ecc-maximize:
> > -        description:
> > -          Whether or not the ECC strength should be maximized. The
> > -          maximum ECC strength is both controller and chip
> > -          dependent. The ECC engine has to select the ECC config
> > -          providing the best strength and taking the OOB area size
> > -          constraint into account. This is particularly useful when
> > -          only the in-band area is used by the upper layers, and you
> > -          want to make your NAND as reliable as possible.
> > -        $ref: /schemas/types.yaml#/definitions/flag
> > -
> > -      nand-is-boot-medium:
> > -        description:
> > -          Whether or not the NAND chip is a boot medium. Drivers might
> > -          use this information to select ECC algorithms supported by
> > -          the boot ROM or similar restrictions.
> > -        $ref: /schemas/types.yaml#/definitions/flag
> > -
> > -      nand-rb:
> > -        description:
> > -          Contains the native Ready/Busy IDs.
> > -        $ref: /schemas/types.yaml#/definitions/uint32-array
> > -
> > -      rb-gpios:
> > -        description:
> > -          Contains one or more GPIO descriptor (the numper of descriptor
> > -          depends on the number of R/B pins exposed by the flash) for the
> > -          Ready/Busy pins. Active state refers to the NAND ready state and
> > -          should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
> > -
> > -      wp-gpios:
> > -        description:
> > -          Contains one GPIO descriptor for the Write Protect pin.
> > -          Active state refers to the NAND Write Protect state and should be
> > -          set to GPIOD_ACTIVE_LOW unless the signal is inverted.
> > -        maxItems: 1
> > -
> > -    required:
> > -      - reg
> > +    type: object
> > +    $ref: raw-nand-chip.yaml#
> >  
> >  required:
> >    - "#address-cells"
> > diff --git a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
> > new file mode 100644
> > index 000000000000..2caa6a9a73d3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
> > @@ -0,0 +1,102 @@
> > +# SPDX-License-Identifier: GPL-2.0  
> 
> Should be dual licensed like the original.

Good catch. I'll wait a few more days, in case there is no other
comment I'll correct when applying. Otherwise I'll address this in v4.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <tudor.ambarus@linaro.org>,
	Pratyush Yadav <pratyush@kernel.org>,
	Michael Walle <michael@walle.cc>,
	linux-mtd@lists.infradead.org,
	Chris Packham <Chris.Packham@alliedtelesis.co.nz>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v3 02/17] dt-bindings: mtd: Create a file for raw NAND chip properties
Date: Tue, 20 Jun 2023 08:18:43 +0200	[thread overview]
Message-ID: <20230620081843.78187721@xps-13> (raw)
In-Reply-To: <20230619225038.GA1676165-robh@kernel.org>

Hi Rob,

robh@kernel.org wrote on Mon, 19 Jun 2023 16:50:38 -0600:

> On Mon, Jun 19, 2023 at 11:29:01AM +0200, Miquel Raynal wrote:
> > In an effort to constrain as much as we can the existing binding, we
> > want to add "unevaluatedProperties: false" in all the NAND chip
> > descriptions part of NAND controller bindings. But in order to do that
> > properly, we also need to reference a file which contains all the
> > "allowed" properties. Right now this file is nand-chip.yaml but in
> > practice raw NAND controllers may use additional properties in their
> > NAND chip children node. These properties are listed under
> > nand-controller.yaml, which makes the "unevaluatedProperties" checks
> > fail while the description are valid. We need to move these NAND chip
> > related properties into another file, because we do not want to pollute
> > nand-chip.yaml which is also referenced by eg. SPI-NAND devices.
> > 
> > Let's create a raw-nand-chip.yaml file to reference all the properties a
> > raw NAND chip description can contain. The chain of inheritance becomes:
> >   nand-controller.yaml <- raw-nand-chip.yaml
> >   raw-nand-chip.yaml   <- nand-chip.yaml
> >   spi-nand.yaml        <- nand-chip.yaml
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> >  .../bindings/mtd/nand-controller.yaml         |  85 +--------------
> >  .../bindings/mtd/raw-nand-chip.yaml           | 102 ++++++++++++++++++
> >  2 files changed, 104 insertions(+), 83 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > index f70a32d2d9d4..83a4fe4cc29d 100644
> > --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> > @@ -16,16 +16,6 @@ description: |
> >    children nodes of the NAND controller. This representation should be
> >    enforced even for simple controllers supporting only one chip.
> >  
> > -  The ECC strength and ECC step size properties define the user
> > -  desires in terms of correction capability of a controller. Together,
> > -  they request the ECC engine to correct {strength} bit errors per
> > -  {size} bytes.
> > -
> > -  The interpretation of these parameters is implementation-defined, so
> > -  not all implementations must support all possible
> > -  combinations. However, implementations are encouraged to further
> > -  specify the value(s) they support.
> > -
> >  properties:
> >    $nodename:
> >      pattern: "^nand-controller(@.*)?"
> > @@ -51,79 +41,8 @@ properties:
> >  
> >  patternProperties:
> >    "^nand@[a-f0-9]$":
> > -    $ref: nand-chip.yaml#
> > -
> > -    properties:
> > -      reg:
> > -        description:
> > -          Contains the chip-select IDs.
> > -
> > -      nand-ecc-placement:
> > -        description:
> > -          Location of the ECC bytes. This location is unknown by default
> > -          but can be explicitly set to "oob", if all ECC bytes are
> > -          known to be stored in the OOB area, or "interleaved" if ECC
> > -          bytes will be interleaved with regular data in the main area.
> > -        $ref: /schemas/types.yaml#/definitions/string
> > -        enum: [ oob, interleaved ]
> > -
> > -      nand-bus-width:
> > -        description:
> > -          Bus width to the NAND chip
> > -        $ref: /schemas/types.yaml#/definitions/uint32
> > -        enum: [8, 16]
> > -        default: 8
> > -
> > -      nand-on-flash-bbt:
> > -        description:
> > -          With this property, the OS will search the device for a Bad
> > -          Block Table (BBT). If not found, it will create one, reserve
> > -          a few blocks at the end of the device to store it and update
> > -          it as the device ages. Otherwise, the out-of-band area of a
> > -          few pages of all the blocks will be scanned at boot time to
> > -          find Bad Block Markers (BBM). These markers will help to
> > -          build a volatile BBT in RAM.
> > -        $ref: /schemas/types.yaml#/definitions/flag
> > -
> > -      nand-ecc-maximize:
> > -        description:
> > -          Whether or not the ECC strength should be maximized. The
> > -          maximum ECC strength is both controller and chip
> > -          dependent. The ECC engine has to select the ECC config
> > -          providing the best strength and taking the OOB area size
> > -          constraint into account. This is particularly useful when
> > -          only the in-band area is used by the upper layers, and you
> > -          want to make your NAND as reliable as possible.
> > -        $ref: /schemas/types.yaml#/definitions/flag
> > -
> > -      nand-is-boot-medium:
> > -        description:
> > -          Whether or not the NAND chip is a boot medium. Drivers might
> > -          use this information to select ECC algorithms supported by
> > -          the boot ROM or similar restrictions.
> > -        $ref: /schemas/types.yaml#/definitions/flag
> > -
> > -      nand-rb:
> > -        description:
> > -          Contains the native Ready/Busy IDs.
> > -        $ref: /schemas/types.yaml#/definitions/uint32-array
> > -
> > -      rb-gpios:
> > -        description:
> > -          Contains one or more GPIO descriptor (the numper of descriptor
> > -          depends on the number of R/B pins exposed by the flash) for the
> > -          Ready/Busy pins. Active state refers to the NAND ready state and
> > -          should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
> > -
> > -      wp-gpios:
> > -        description:
> > -          Contains one GPIO descriptor for the Write Protect pin.
> > -          Active state refers to the NAND Write Protect state and should be
> > -          set to GPIOD_ACTIVE_LOW unless the signal is inverted.
> > -        maxItems: 1
> > -
> > -    required:
> > -      - reg
> > +    type: object
> > +    $ref: raw-nand-chip.yaml#
> >  
> >  required:
> >    - "#address-cells"
> > diff --git a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
> > new file mode 100644
> > index 000000000000..2caa6a9a73d3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
> > @@ -0,0 +1,102 @@
> > +# SPDX-License-Identifier: GPL-2.0  
> 
> Should be dual licensed like the original.

Good catch. I'll wait a few more days, in case there is no other
comment I'll correct when applying. Otherwise I'll address this in v4.

Thanks,
Miquèl

  reply	other threads:[~2023-06-20  6:19 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-19  9:28 [PATCH v3 00/17] Prevent NAND chip unevaluated properties Miquel Raynal
2023-06-19  9:28 ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 01/17] dt-bindings: mtd: Accept nand related node names Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:16   ` Miquel Raynal
2023-06-22 21:16     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 02/17] dt-bindings: mtd: Create a file for raw NAND chip properties Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-19 22:50   ` Rob Herring
2023-06-19 22:50     ` Rob Herring
2023-06-20  6:18     ` Miquel Raynal [this message]
2023-06-20  6:18       ` Miquel Raynal
2023-06-22 21:05     ` Miquel Raynal
2023-06-22 21:05       ` Miquel Raynal
2023-06-22 21:16   ` Miquel Raynal
2023-06-22 21:16     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 03/17] dt-bindings: mtd: Mark nand-ecc-placement deprecated Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:16   ` Miquel Raynal
2023-06-22 21:16     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 04/17] dt-bindings: mtd: Describe nand-ecc-mode Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:16   ` Miquel Raynal
2023-06-22 21:16     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 05/17] dt-bindings: mtd: qcom: Fix a property position Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:16   ` Miquel Raynal
2023-06-22 21:16     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 06/17] dt-bindings: mtd: qcom: Prevent NAND chip unevaluated properties Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 07/17] dt-bindings: mtd: ingenic: " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 08/17] dt-bindings: mtd: sunxi: " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 09/17] dt-bindings: mtd: meson: " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 10/17] dt-bindings: mtd: brcmnand: " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 11/17] dt-bindings: mtd: denali: " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 12/17] dt-bindings: mtd: intel: " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 13/17] dt-bindings: mtd: rockchip: " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 14/17] dt-bindings: mtd: stm32: " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 15/17] dt-bindings: mtd: mediatek: Reference raw-nand-chip.yaml Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:15   ` Miquel Raynal
2023-06-22 21:15     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 16/17] dt-bindings: mtd: mediatek: Prevent NAND chip unevaluated properties Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:14   ` Miquel Raynal
2023-06-22 21:14     ` Miquel Raynal
2023-06-19  9:29 ` [PATCH v3 17/17] dt-bindings: mtd: ti,am654: Prevent " Miquel Raynal
2023-06-19  9:29   ` Miquel Raynal
2023-06-22 21:14   ` Miquel Raynal
2023-06-22 21:14     ` Miquel Raynal

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=20230620081843.78187721@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=robh@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tudor.ambarus@linaro.org \
    --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.