On 26/10/2022 17:57, Vadym Kochan wrote: >>> + interrupts: >>> + maxItems: 1 >>> + >>> + clocks: >> >> What happened to maxItems here? This is wrong. You keep changing random >> things, again. V3 was correct. >> > > It is not random, I tried to enforce to use 2 clocks for A7k/8K case. I think I gave you example how these clocks are being enforced, but let's paste it here one more time: https://elixir.bootlin.com/linux/v5.19-rc6/source/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml#L38 If you have always two clocks, you just put here maxItems and skip the allOf:if:then. If you have here for some variants one clock, for some two, then define wide constraints here and narrow them for each variant in allOf:if:then ("else:") > >> >>> + description: >>> + Shall reference the NAND controller clocks, the second one is >>> + is only needed for the Armada 7K/8K SoCs >>> + >>> + clock-names: >>> + items: >>> + - const: core >>> + - const: reg >>> + >>> + dmas: >>> + maxItems: 1 >>> + >>> + dma-names: >>> + items: >>> + - const: rxtx >>> + >>> + marvell,system-controller: >>> + $ref: /schemas/types.yaml#/definitions/phandle >>> + description: Syscon node that handles NAND controller related registers >>> + >>> +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. Best regards, Krzysztof
