On 12/2/22 17:57, Miquel Raynal wrote:
Hi Marek,
Hi,
On 12/2/22 17:42, Miquel Raynal wrote:
Hi Marek,
Hi,
[...]
However, it should not be empty, at the very least a reg property should indicate on which CS it is wired, as expected there: https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/tree/Documenta...
OK, I see your point. So basically this?
&gpmi { #size-cells = <1>; ... nand-chip@0 { reg = <0>; }; };
btw. the GPMI NAND controller supports only one chipselect, so the reg in nand-chip node makes little sense.
I randomly opened a reference manual (IMX6DQL.pdf), they say:
"Up to four NAND devices, supported by four chip-selects and one ganged ready/ busy."
Doh, and MX7D has the same controller, so size-cells = <1>; makes sense with nand-chip@N {} .
Actually #address-cells is here for that. You need to point at one CS, so in most cases this is:
controller { #address-cells = <1>; #size-cells = <0>; chip@N { reg = <N>; }; };
Right ... thanks for spotting this.
But then the size-cells in the controller node should be zero. And 753395ea1e45 ("ARM: dts: imx7: Fix NAND controller size-cells") is therefore correct ?
But that correction in 753395ea1e45 breaks setup where old U-Boot injects partition@N directly into the nand-controller node, without updating the nand-controller node size-cells, i.e. this: nand-controller { #address-cells = <1>; #size-cells = <0>;
+ partition@0 { ... }; }; Because the size-cells is 0 in that case, and U-Boot does not update the size-cells .
It used to work before because Linux DT contained size-cells=<1> in the nand-controller node before 753395ea1e45 ("ARM: dts: imx7: Fix NAND controller size-cells").
But here I would say this is a firmware bug and it might have to be handled like a firmware bug, i.e. with fixup in the partition parser. I seem to be changing my opinion here again.