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
