[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e937b059-4168-3bd4-b294-cbfff0519d1f@linaro.org>
Date: Thu, 27 Oct 2022 09:24:24 -0400
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>
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
On 27/10/2022 09:18, Miquel Raynal wrote:
> 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.
Which is not included here and in nand-controller.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).
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).
Best regards,
Krzysztof
Powered by blists - more mailing lists