linux-kernel - Re: [PATCH] dt-bindings: mtd: nvidia,tegra20-nand: convert to DT schema

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251104-prompt-rampant-cat-30fd9a@kuoka>
Date: Tue, 4 Nov 2025 11:03:01 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Charan Pedumuru <charan.pedumuru@...il.com>
Cc: Miquel Raynal <miquel.raynal@...tlin.com>, 
	Richard Weinberger <richard@....at>, Vignesh Raghavendra <vigneshr@...com>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Thierry Reding <thierry.reding@...il.com>, 
	Jonathan Hunter <jonathanh@...dia.com>, Stefan Agner <stefan@...er.ch>, Lucas Stach <dev@...xeye.de>, 
	linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org, linux-tegra@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: nvidia,tegra20-nand: convert to DT
 schema

On Thu, Oct 30, 2025 at 06:47:25PM +0000, Charan Pedumuru wrote:
> Convert NVIDIA Tegra NAND Flash Controller binding to YAML format.
> Changes during Conversion:
> - Define new properties `power-domains` and `operating-points-v2`
>   to resolve errors generated by `dtb_check`.

instead - because existing in-tree DTS uses them.

> - Add the `#address-cells` and `#size-cells` properties to the parent
>   node to fix errors reported by `dt_check`, and include these properties

What is dt_check? Aren't you adding them because other schema requires
them? Then say that (and which schema...).


>   in the `required` section, as they are not mentioned in the text binding.
> 
> Signed-off-by: Charan Pedumuru <charan.pedumuru@...il.com>
> ---
>  .../bindings/mtd/nvidia,tegra20-nand.yaml          | 157 +++++++++++++++++++++
>  .../bindings/mtd/nvidia-tegra20-nand.txt           |  64 ---------
>  2 files changed, 157 insertions(+), 64 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/nvidia,tegra20-nand.yaml b/Documentation/devicetree/bindings/mtd/nvidia,tegra20-nand.yaml
> new file mode 100644
> index 000000000000..67b3c45566db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/nvidia,tegra20-nand.yaml
> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/nvidia,tegra20-nand.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra NAND Flash Controller
> +
> +maintainers:
> +  - Jonathan Hunter <jonathanh@...dia.com>
> +
> +description:
> +  Device tree bindings for the NVIDIA Tegra NAND Flash Controller (NFC).

Drop sentencem completely redundant. Title already said that.

> +  The controller supports a single NAND chip with specific properties.

What is/are "specific properties"? Can properties be unspecific?

> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra20-nand
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    items:
> +      - const: nand
> +
> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    items:
> +      - const: nand
> +
> +  '#address-cells':
> +    const: 1
> +
> +  '#size-cells':
> +    const: 0
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  operating-points-v2:
> +    maxItems: 1
> +
> +patternProperties:
> +  "^nand@[0-5]$":

Keep consistent quotes, either ' or "

> +    type: object
> +    description: Individual NAND chip connected to the NAND controller
> +    properties:
> +      reg:
> +        maxItems: 1
> +
> +      nand-ecc-mode:
> +        description:
> +          Operation mode of the NAND ECC, currently only hardware
> +          mode supported
> +        const: hw
> +
> +      nand-ecc-algo:
> +        description: Algorithm for NAND ECC when using hw ECC mode
> +        enum:
> +          - rs
> +          - bch
> +
> +      nand-bus-width:
> +        description: Width of the NAND flash bus in bits
> +        enum: [8, 16]
> +        default: 8
> +
> +      nand-on-flash-bbt:
> +        description: Use an on-flash bad block table to track bad blocks
> +        type: boolean
> +
> +      nand-ecc-maximize:

Why are you duplicating all these properties from nand schema?

> +        description:
> +          Maximize ECC strength for the NAND chip, overriding
> +          default strength selection
> +        type: boolean
> +
> +      nand-ecc-strength:
> +        description: Number of bits to correct per ECC step (512 bytes)
> +        enum: [4, 6, 8, 14, 16]
> +
> +      nand-is-boot-medium:
> +        description: Ensures ECC strengths are compatible with the boot ROM
> +        type: boolean
> +
> +      wp-gpios:
> +        description: GPIO specifier for the write protect pin
> +        maxItems: 1
> +
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 1
> +
> +    patternProperties:
> +      "^partition@[0-9a-f]+$":
> +        $ref: /schemas/mtd/mtd.yaml#
> +        description:
> +          Optional MTD partitions for the NAND chip, as defined in mtd.yaml
> +
> +    required:
> +      - reg
> +
> +    unevaluatedProperties: false

So this should tell you that you miss proper ref

> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - resets
> +  - reset-names
> +  - '#address-cells'
> +  - '#size-cells'
> +
> +unevaluatedProperties: false

Same here. Why do you use unevaluatedProperties if there is no ref?
Please open other bindings to understand how MTD binding should be
written.

Best regards,
Krzysztof