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

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

On 27/10/2022 09:50, Miquel Raynal wrote:
> Hi Krzysztof,
> 
> krzysztof.kozlowski@linaro.org wrote on Thu, 27 Oct 2022 09:24:24 -0400:
> 
>> 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
> 
> Maybe nand-chip.yaml should?

mtd.yaml looks a bit more than that - also allows nvmem nodes. Maybe
let's just add label to nand-chip?

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

Ah, right. Then it seems reasonable.

> 
> 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.
> 
> 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/bindings/mtd/ti,gpmc-nand.yaml
> https://elixir.bootlin.com/linux/v6.0/source/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml


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.

Best regards,
Krzysztof


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/