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

Charan Pedumuru charan.pedumuru at gmail.com
Thu Dec 11 08:29:28 PST 2025



On 04-11-2025 15:33, Krzysztof Kozlowski wrote:
> 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...).

Sure, I will modify accordingly.

> 
> 
>>   in the `required` section, as they are not mentioned in the text binding.
>>
>> Signed-off-by: Charan Pedumuru <charan.pedumuru at gmail.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 at nvidia.com>
>> +
>> +description:
>> +  Device tree bindings for the NVIDIA Tegra NAND Flash Controller (NFC).
> 
> Drop sentencem completely redundant. Title already said that.

Okay.

> 
>> +  The controller supports a single NAND chip with specific properties.
> 
> What is/are "specific properties"? Can properties be unspecific?

I will modify the description.

> 
>> +
>> +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 "

Sure.

> 
>> +    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?

Sure, I will make nand-chip as ref and remove duplicate properties.

> 
>> +        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.

I will add appropriate common nand-controller ref to the schema.

> 
> Best regards,
> Krzysztof
> 

-- 
Best Regards,
Charan.




More information about the linux-mtd mailing list