linux-kernel - Re: [PATCH v5 1/2] dt-bindings: mtd: marvell-nand: Convert to YAML DT scheme

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221027151825.166a9255@xps-13>
Date:   Thu, 27 Oct 2022 15:18:25 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Vadym Kochan <vadym.kochan@...ision.eu>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Elad Nachman <enachman@...vell.com>,
        Chris Packham <chris.packham@...iedtelesis.co.nz>
Subject: Re: [PATCH v5 1/2] dt-bindings: mtd: marvell-nand: Convert to YAML
 DT scheme

Hi Vadym,

> >>> +patternProperties:
> >>> +  "^nand@[0-3]$":
> >>> +    type: object
> >>> +    properties:
> >>> +      reg:
> >>> +        minimum: 0
> >>> +        maximum: 3
> >>> +
> >>> +      nand-rb:
> >>> +        minimum: 0
> >>> +        maximum: 1
> >>> +
> >>> +      nand-ecc-strength:
> >>> +        enum: [1, 4, 8]
> >>> +
> >>> +      nand-on-flash-bbt: true
> >>> +
> >>> +      nand-ecc-mode: true
> >>> +
> >>> +      nand-ecc-algo:
> >>> +        description: |
> >>> +          This property is essentially useful when not using hardware ECC.
> >>> +          Howerver, it may be added when using hardware ECC for clarification
> >>> +          but will be ignored by the driver because ECC mode is chosen depending
> >>> +          on the page size and the strength required by the NAND chip.
> >>> +          This value may be overwritten with nand-ecc-strength property.
> >>> +
> >>> +      nand-ecc-step-size:
> >>> +        description: |
> >>> +          Marvell's NAND flash controller does use fixed strength
> >>> +          (1-bit for Hamming, 16-bit for BCH), so the actual step size
> >>> +          will shrink or grow in order to fit the required strength.
> >>> +          Step sizes are not completely random for all and follow certain
> >>> +          patterns described in AN-379, "Marvell SoC NFC ECC".
> >>> +
> >>> +      label:
> >>> +        $ref: /schemas/types.yaml#/definitions/string
> >>> +
> >>> +      partitions:
> >>> +        type: object  
> >>
> >> That's not what I asked for. Like four times I asked you to add here
> >> unevaluatedProperties: false and I never said that ref to partition.yaml
> >> should be removed and you... instead remove that ref.
> >>
> >> You need to define here children and specify their ref.
> >>
> >> You must use unevaluatedProperties: false here. So this is fifth time I
> >> am writing this feedback.
> >>
> >>  
> > 
> > It is a bit confusing that it is needed to define "partitions" and "label" rules particulary
> > in this nand controller instead of some common place like nand-chip.yaml, these properties
> > are common also for the other nand controllers.  
> 
> No one speaks about label, I never commented about label, I think...
> 
> If you think the property is really generic and every NAND controller
> bindings implement it, then feel free to include them there, in a
> separate patch. It sounds sensible, but I did not check other bindings.

FYI, label is already defined in mtd/mtd.yaml.

Partitions do not need to be defined in your binding, just don't put
any in your example and you'll be fine. These partitions are either
static and may be described in the DT (see
mtd/partition/partition.yaml) or there is some dynamic discovery
involved and a proper parser shall be referenced (parsers have their
own binding).

Cheers,
Miquèl