Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 28 Oct 2022 09:47:40 +0200
From:   Miquel Raynal <miquel.raynal@bootlin.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Vadym Kochan <vadym.kochan@plvision.eu>,
        Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Andrew Lunn <andrew@lunn.ch>,
        Gregory Clement <gregory.clement@bootlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
        linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        Elad Nachman <enachman@marvell.com>,
        Chris Packham <chris.packham@alliedtelesis.co.nz>
Subject: Re: [PATCH v5 1/2] dt-bindings: mtd: marvell-nand: Convert to YAML
 DT scheme
Message-ID: <20221028094740.3c11f52b@xps-13>
In-Reply-To: <683dffbc-744f-80cd-2262-b6deb4200ccc@linaro.org>
References: <20221026134545.7146-1-vadym.kochan@plvision.eu>
        <20221026134545.7146-2-vadym.kochan@plvision.eu>
        <33f04b06-dc00-b7ce-6a24-2282608b40dc@linaro.org>
        <VI1P190MB0317C739E2D39427CD2A771D95309@VI1P190MB0317.EURP190.PROD.OUTLOOK.COM>
        <10581088-e4ff-76db-3c9b-42a7a9c118ee@linaro.org>
        <20221027151825.166a9255@xps-13>
        <e937b059-4168-3bd4-b294-cbfff0519d1f@linaro.org>
        <20221027155025.7c04774a@xps-13>
        <683dffbc-744f-80cd-2262-b6deb4200ccc@linaro.org>
Organization: Bootlin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Krzysztof,

krzysztof.kozlowski@linaro.org wrote on Thu, 27 Oct 2022 10:51:29 -0400:

> On 27/10/2022 09:50, Miquel Raynal wrote:
> > Hi Krzysztof,
> >=20
> > krzysztof.kozlowski@linaro.org wrote on Thu, 27 Oct 2022 09:24:24 -0400:
> >  =20
> >> On 27/10/2022 09:18, Miquel Raynal wrote: =20
> >>> Hi Vadym,
> >>>    =20
> >>>>>>> +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 har=
dware 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 p=
roperty.
> >>>>>>> +
> >>>>>>> +      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 ste=
p size
> >>>>>>> +          will shrink or grow in order to fit the required stren=
gth.
> >>>>>>> +          Step sizes are not completely random for all and follo=
w certain
> >>>>>>> +          patterns described in AN-379, "Marvell SoC NFC ECC".
> >>>>>>> +
> >>>>>>> +      label:
> >>>>>>> +        $ref: /schemas/types.yaml#/definitions/string
> >>>>>>> +
> >>>>>>> +      partitions:
> >>>>>>> +        type: object     =20
> >>>>>>
> >>>>>> That's not what I asked for. Like four times I asked you to add he=
re
> >>>>>> unevaluatedProperties: false and I never said that ref to partitio=
n.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 t=
ime I
> >>>>>> am writing this feedback.
> >>>>>>
> >>>>>>     =20
> >>>>>
> >>>>> 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.     =20
> >>>>
> >>>> 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 bindin=
gs.   =20
> >>>
> >>> FYI, label is already defined in mtd/mtd.yaml.   =20
> >>
> >> Which is not included here and in nand-controller.yaml =20
> >=20
> > Maybe nand-chip.yaml should? =20
>=20
> mtd.yaml looks a bit more than that - also allows nvmem nodes. Maybe
> let's just add label to nand-chip?

I don't get the reason behind this proposal, mtd.yaml really is
kind of a definition of generic properties any mtd device might
have, so duplicating label (or whatever else inside) does not seem
legitimate to me. The jedec,spi-nor.yaml file already references it for
instance.

> >>> 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).   =20
> >>
> >> I don't think this is correct. Basically you allow any node to be under
> >> partitions as there is no schema validating them (without compatibles)=
. =20
> >=20
> > Sorry if that was unclear, what I meant is: partitions should not be
> > defined in the bindings for Marvell NAND controller because they should
> > be defined somewhere else already. =20
>=20
> Ah, right. Then it seems reasonable.
>=20
> >=20
> > NAND controller subnodes should define the storage devices (the
> > flashes themselves) connected to the controller. "nand-chip.yaml"
> > describes generic properties for these. Additional subnodes are allowed
> > and expected to be partitions (this is not enforced anywhere I think),
> > they should use one of the existing compatibles to define the parser.
> > The most common parser is named fixed-partitions and has its own
> > compatible. Every parser references partitions.yaml.
> >=20
> > There are a few controller bindings however which reference
> > partition.yaml anyway, probably to make the examples validation work,
> > I'm not sure it should be done like that though:
> > https://elixir.bootlin.com/linux/v6.0/source/Documentation/devicetree/b=
indings/mtd/ti,gpmc-nand.yaml
> > https://elixir.bootlin.com/linux/v6.0/source/Documentation/devicetree/b=
indings/mtd/ti,gpmc-onenand.yaml =20
>=20
>=20
> Yes, so the nand-chip implementation (like Marvell NAND) could reference
> the parser and we would be done. If it doesn't, then we must have
> generic partitions in the nand-chip.

In this case, I am not aware of any parser that would be relevant.

In the generic case, should we really reference a parser in particular?
If yes then maybe we should make a yaml file that just gathers all the
parsers and include it within mtd.yaml (and have it referenced in
nand-chip.yaml). What do you think?

Thanks,
Miqu=C3=A8l