From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: Marek Vasut <marex@denx.de>, Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd@lists.infradead.org,
Francesco Dolcini <francesco.dolcini@toradex.com>,
Shawn Guo <shawnguo@kernel.org>,
linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org,
u-boot@lists.denx.de
Subject: Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
Date: Fri, 2 Dec 2022 18:05:28 +0100 [thread overview]
Message-ID: <20221202180528.173ee343@xps-13> (raw)
In-Reply-To: <Y4orsUIp3Ffz8m+r@francesco-nb.int.toradex.com>
Hi Francesco,
francesco@dolcini.it wrote on Fri, 2 Dec 2022 17:45:37 +0100:
> On Fri, Dec 02, 2022 at 05:17:59PM +0100, Marek Vasut wrote:
> > On 12/2/22 16:49, Miquel Raynal wrote:
> > > , not the NAND controller node. I hope this
> > > is correctly supported in U-Boot though. So if there is a NAND chip
> > > subnode, I suppose U-Boot would try to create the partitions that are
> > > inside, or even in the sub "partitions" container.
> >
> > My understanding is that U-Boot checks the nand-controller node size-cells,
> > not the nand-chip{} or partitions{} subnode size-cells .
> Not 100% correct.
>
> - U-Boot before v2022.04 updates the nand-controller{} node, no matter what.
> - U-Boot starting from v2022.04 looks for `partitions{}` into the
> nand-controller{} node, and creates the partition into it if found.
> If not found it behaves the same way as the previous versions.
> See commit 36fee2f7621e ("common: fdt_support: add support for "partitions" subnode to fdt_fixup_mtdparts()")
>
> I'd like to stress once more the fact that we cannot expect old U-Boot
> to be updated in the field, and they will keep generating the partitions
> as child of the nand-controller node whatever we do with the dts file.
>
> I think that this should be treated the same way as any other fixup we
> might have for broken firmware, especially considering that this used to
> "work" (yes, I can agree that it horrible, but I cannot change the past)
> without even a warning since the imx7 support was first introduced in
> the linux kernel years ago.
>
> > Francesco, can you please share the DT, including the U-Boot generated
> > partitions, which is passed to Linux on Colibri MX7 ? I think that should
> > make all confusion go away.
>
> The device tree part is easy, just
> arch/arm/boot/dts/imx7d-colibri-eval-v3.dts.
>
> and the nand-controller node is coming from
>
> #include "imx7d.dtsi"
>
> plus
>
> &gpmi {
> fsl,use-minimum-ecc;
> nand-ecc-mode = "hw";
> nand-on-flash-bbt;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_gpmi_nand>;
> };
>
> The partitions nodes are generated 100% by U-Boot, nothing is present in
> the dts source files.
I hope if you provide a NAND chip child node, the partitions are created
at the right location, otherwise this is so, so wrong...
>
> With this DTS file as input, whatever U-Boot version is used I have the
> following generated:
>
> root@colibri-imx7-02844233:/# ls /proc/device-tree/soc/nand-controller@33002000/
> #address-cells dma-names nand-on-flash-bbt pinctrl-0
> #size-cells dmas partition@0 pinctrl-names
> assigned-clock-parents fsl,use-minimum-ecc partition@200000 reg
> assigned-clocks interrupt-names partition@380000 reg-names
> clock-names interrupts partition@400000 status
> clocks name partition@80000
> compatible nand-ecc-mode phandle
>
> root@colibri-imx7-02844233:/# ls /proc/device-tree/soc/nand-controller@33002000/partition@*
> /proc/device-tree/soc/nand-controller@33002000/partition@0:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@200000:
> label name read_only reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@380000:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@400000:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@80000:
> label name read_only reg
>
>
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: Marek Vasut <marex@denx.de>, Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd@lists.infradead.org,
Francesco Dolcini <francesco.dolcini@toradex.com>,
Shawn Guo <shawnguo@kernel.org>,
linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org,
u-boot@lists.denx.de
Subject: Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
Date: Fri, 2 Dec 2022 18:05:28 +0100 [thread overview]
Message-ID: <20221202180528.173ee343@xps-13> (raw)
In-Reply-To: <Y4orsUIp3Ffz8m+r@francesco-nb.int.toradex.com>
Hi Francesco,
francesco@dolcini.it wrote on Fri, 2 Dec 2022 17:45:37 +0100:
> On Fri, Dec 02, 2022 at 05:17:59PM +0100, Marek Vasut wrote:
> > On 12/2/22 16:49, Miquel Raynal wrote:
> > > , not the NAND controller node. I hope this
> > > is correctly supported in U-Boot though. So if there is a NAND chip
> > > subnode, I suppose U-Boot would try to create the partitions that are
> > > inside, or even in the sub "partitions" container.
> >
> > My understanding is that U-Boot checks the nand-controller node size-cells,
> > not the nand-chip{} or partitions{} subnode size-cells .
> Not 100% correct.
>
> - U-Boot before v2022.04 updates the nand-controller{} node, no matter what.
> - U-Boot starting from v2022.04 looks for `partitions{}` into the
> nand-controller{} node, and creates the partition into it if found.
> If not found it behaves the same way as the previous versions.
> See commit 36fee2f7621e ("common: fdt_support: add support for "partitions" subnode to fdt_fixup_mtdparts()")
>
> I'd like to stress once more the fact that we cannot expect old U-Boot
> to be updated in the field, and they will keep generating the partitions
> as child of the nand-controller node whatever we do with the dts file.
>
> I think that this should be treated the same way as any other fixup we
> might have for broken firmware, especially considering that this used to
> "work" (yes, I can agree that it horrible, but I cannot change the past)
> without even a warning since the imx7 support was first introduced in
> the linux kernel years ago.
>
> > Francesco, can you please share the DT, including the U-Boot generated
> > partitions, which is passed to Linux on Colibri MX7 ? I think that should
> > make all confusion go away.
>
> The device tree part is easy, just
> arch/arm/boot/dts/imx7d-colibri-eval-v3.dts.
>
> and the nand-controller node is coming from
>
> #include "imx7d.dtsi"
>
> plus
>
> &gpmi {
> fsl,use-minimum-ecc;
> nand-ecc-mode = "hw";
> nand-on-flash-bbt;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_gpmi_nand>;
> };
>
> The partitions nodes are generated 100% by U-Boot, nothing is present in
> the dts source files.
I hope if you provide a NAND chip child node, the partitions are created
at the right location, otherwise this is so, so wrong...
>
> With this DTS file as input, whatever U-Boot version is used I have the
> following generated:
>
> root@colibri-imx7-02844233:/# ls /proc/device-tree/soc/nand-controller@33002000/
> #address-cells dma-names nand-on-flash-bbt pinctrl-0
> #size-cells dmas partition@0 pinctrl-names
> assigned-clock-parents fsl,use-minimum-ecc partition@200000 reg
> assigned-clocks interrupt-names partition@380000 reg-names
> clock-names interrupts partition@400000 status
> clocks name partition@80000
> compatible nand-ecc-mode phandle
>
> root@colibri-imx7-02844233:/# ls /proc/device-tree/soc/nand-controller@33002000/partition@*
> /proc/device-tree/soc/nand-controller@33002000/partition@0:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@200000:
> label name read_only reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@380000:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@400000:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@80000:
> label name read_only reg
>
>
Thanks,
Miquèl
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: Marek Vasut <marex@denx.de>, Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd@lists.infradead.org,
Francesco Dolcini <francesco.dolcini@toradex.com>,
Shawn Guo <shawnguo@kernel.org>,
linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org,
u-boot@lists.denx.de
Subject: Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
Date: Fri, 2 Dec 2022 18:05:28 +0100 [thread overview]
Message-ID: <20221202180528.173ee343@xps-13> (raw)
In-Reply-To: <Y4orsUIp3Ffz8m+r@francesco-nb.int.toradex.com>
Hi Francesco,
francesco@dolcini.it wrote on Fri, 2 Dec 2022 17:45:37 +0100:
> On Fri, Dec 02, 2022 at 05:17:59PM +0100, Marek Vasut wrote:
> > On 12/2/22 16:49, Miquel Raynal wrote:
> > > , not the NAND controller node. I hope this
> > > is correctly supported in U-Boot though. So if there is a NAND chip
> > > subnode, I suppose U-Boot would try to create the partitions that are
> > > inside, or even in the sub "partitions" container.
> >
> > My understanding is that U-Boot checks the nand-controller node size-cells,
> > not the nand-chip{} or partitions{} subnode size-cells .
> Not 100% correct.
>
> - U-Boot before v2022.04 updates the nand-controller{} node, no matter what.
> - U-Boot starting from v2022.04 looks for `partitions{}` into the
> nand-controller{} node, and creates the partition into it if found.
> If not found it behaves the same way as the previous versions.
> See commit 36fee2f7621e ("common: fdt_support: add support for "partitions" subnode to fdt_fixup_mtdparts()")
>
> I'd like to stress once more the fact that we cannot expect old U-Boot
> to be updated in the field, and they will keep generating the partitions
> as child of the nand-controller node whatever we do with the dts file.
>
> I think that this should be treated the same way as any other fixup we
> might have for broken firmware, especially considering that this used to
> "work" (yes, I can agree that it horrible, but I cannot change the past)
> without even a warning since the imx7 support was first introduced in
> the linux kernel years ago.
>
> > Francesco, can you please share the DT, including the U-Boot generated
> > partitions, which is passed to Linux on Colibri MX7 ? I think that should
> > make all confusion go away.
>
> The device tree part is easy, just
> arch/arm/boot/dts/imx7d-colibri-eval-v3.dts.
>
> and the nand-controller node is coming from
>
> #include "imx7d.dtsi"
>
> plus
>
> &gpmi {
> fsl,use-minimum-ecc;
> nand-ecc-mode = "hw";
> nand-on-flash-bbt;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_gpmi_nand>;
> };
>
> The partitions nodes are generated 100% by U-Boot, nothing is present in
> the dts source files.
I hope if you provide a NAND chip child node, the partitions are created
at the right location, otherwise this is so, so wrong...
>
> With this DTS file as input, whatever U-Boot version is used I have the
> following generated:
>
> root@colibri-imx7-02844233:/# ls /proc/device-tree/soc/nand-controller@33002000/
> #address-cells dma-names nand-on-flash-bbt pinctrl-0
> #size-cells dmas partition@0 pinctrl-names
> assigned-clock-parents fsl,use-minimum-ecc partition@200000 reg
> assigned-clocks interrupt-names partition@380000 reg-names
> clock-names interrupts partition@400000 status
> clocks name partition@80000
> compatible nand-ecc-mode phandle
>
> root@colibri-imx7-02844233:/# ls /proc/device-tree/soc/nand-controller@33002000/partition@*
> /proc/device-tree/soc/nand-controller@33002000/partition@0:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@200000:
> label name read_only reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@380000:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@400000:
> label name reg
>
> /proc/device-tree/soc/nand-controller@33002000/partition@80000:
> label name read_only reg
>
>
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-02 17:06 UTC|newest]
Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 7:19 [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0 Francesco Dolcini
2022-12-02 7:19 ` Francesco Dolcini
2022-12-02 7:19 ` Francesco Dolcini
2022-12-02 9:14 ` Miquel Raynal
2022-12-02 9:14 ` Miquel Raynal
2022-12-02 9:14 ` Miquel Raynal
2022-12-02 10:12 ` Francesco Dolcini
2022-12-02 10:12 ` Francesco Dolcini
2022-12-02 10:12 ` Francesco Dolcini
2022-12-02 10:24 ` Francesco Dolcini
2022-12-02 10:24 ` Francesco Dolcini
2022-12-02 10:24 ` Francesco Dolcini
2022-12-02 10:53 ` Miquel Raynal
2022-12-02 10:53 ` Miquel Raynal
2022-12-02 10:53 ` Miquel Raynal
2022-12-02 11:23 ` Francesco Dolcini
2022-12-02 11:23 ` Francesco Dolcini
2022-12-02 11:23 ` Francesco Dolcini
2022-12-02 14:05 ` Miquel Raynal
2022-12-02 14:05 ` Miquel Raynal
2022-12-02 14:05 ` Miquel Raynal
2022-12-02 14:31 ` Marek Vasut
2022-12-02 14:31 ` Marek Vasut
2022-12-02 14:31 ` Marek Vasut
2022-12-02 15:00 ` Miquel Raynal
2022-12-02 15:00 ` Miquel Raynal
2022-12-02 15:00 ` Miquel Raynal
2022-12-02 15:23 ` Marek Vasut
2022-12-02 15:23 ` Marek Vasut
2022-12-02 15:23 ` Marek Vasut
2022-12-02 15:49 ` Miquel Raynal
2022-12-02 15:49 ` Miquel Raynal
2022-12-02 15:49 ` Miquel Raynal
2022-12-02 16:01 ` Miquel Raynal
2022-12-02 16:01 ` Miquel Raynal
2022-12-02 16:01 ` Miquel Raynal
2022-12-02 16:17 ` Marek Vasut
2022-12-02 16:17 ` Marek Vasut
2022-12-02 16:17 ` Marek Vasut
2022-12-02 16:42 ` Miquel Raynal
2022-12-02 16:42 ` Miquel Raynal
2022-12-02 16:42 ` Miquel Raynal
2022-12-02 16:52 ` Marek Vasut
2022-12-02 16:52 ` Marek Vasut
2022-12-02 16:52 ` Marek Vasut
2022-12-02 16:57 ` Miquel Raynal
2022-12-02 16:57 ` Miquel Raynal
2022-12-02 16:57 ` Miquel Raynal
2022-12-02 17:08 ` Marek Vasut
2022-12-02 17:08 ` Marek Vasut
2022-12-02 17:08 ` Marek Vasut
2022-12-05 11:26 ` Francesco Dolcini
2022-12-05 11:26 ` Francesco Dolcini
2022-12-05 11:26 ` Francesco Dolcini
2022-12-05 13:49 ` Miquel Raynal
2022-12-05 13:49 ` Miquel Raynal
2022-12-05 13:49 ` Miquel Raynal
2022-12-05 16:25 ` Marek Vasut
2022-12-05 16:25 ` Marek Vasut
2022-12-05 16:25 ` Marek Vasut
2022-12-15 7:16 ` Miquel Raynal
2022-12-15 7:16 ` Miquel Raynal
2022-12-15 7:16 ` Miquel Raynal
2022-12-15 7:45 ` Marek Vasut
2022-12-15 7:45 ` Marek Vasut
2022-12-15 7:45 ` Marek Vasut
2022-12-15 8:04 ` Miquel Raynal
2022-12-15 8:04 ` Miquel Raynal
2022-12-15 8:04 ` Miquel Raynal
2022-12-16 0:36 ` Marek Vasut
2022-12-16 0:36 ` Marek Vasut
2022-12-16 0:36 ` Marek Vasut
2022-12-16 7:52 ` Francesco Dolcini
2022-12-16 7:52 ` Francesco Dolcini
2022-12-16 7:52 ` Francesco Dolcini
2022-12-16 7:45 ` Francesco Dolcini
2022-12-16 7:45 ` Francesco Dolcini
2022-12-16 7:45 ` Francesco Dolcini
2022-12-16 10:46 ` Marek Vasut
2022-12-16 10:46 ` Marek Vasut
2022-12-16 10:46 ` Marek Vasut
2022-12-16 11:01 ` Miquel Raynal
2022-12-16 11:01 ` Miquel Raynal
2022-12-16 11:01 ` Miquel Raynal
2022-12-16 12:37 ` Francesco Dolcini
2022-12-16 12:37 ` Francesco Dolcini
2022-12-16 12:37 ` Francesco Dolcini
2022-12-16 13:37 ` Miquel Raynal
2022-12-16 13:37 ` Miquel Raynal
2022-12-16 13:37 ` Miquel Raynal
2022-12-16 14:32 ` Marek Vasut
2022-12-16 14:32 ` Marek Vasut
2022-12-16 14:32 ` Marek Vasut
2022-12-16 15:35 ` Miquel Raynal
2022-12-16 15:35 ` Miquel Raynal
2022-12-16 15:35 ` Miquel Raynal
2022-12-16 16:30 ` Francesco Dolcini
2022-12-16 16:30 ` Francesco Dolcini
2022-12-16 16:30 ` Francesco Dolcini
2023-01-02 9:40 ` Miquel Raynal
2023-01-02 9:40 ` Miquel Raynal
2023-01-02 9:40 ` Miquel Raynal
2023-01-05 11:33 ` Miquel Raynal
2023-01-05 11:33 ` Miquel Raynal
2023-01-05 11:33 ` Miquel Raynal
2023-01-05 12:47 ` Francesco Dolcini
2023-01-05 12:47 ` Francesco Dolcini
2023-01-05 12:47 ` Francesco Dolcini
2023-01-05 14:51 ` Marek Vasut
2023-01-05 14:51 ` Marek Vasut
2023-01-05 14:51 ` Marek Vasut
2023-01-05 15:03 ` Miquel Raynal
2023-01-05 15:03 ` Miquel Raynal
2023-01-05 15:03 ` Miquel Raynal
2022-12-02 17:20 ` Francesco Dolcini
2022-12-02 17:20 ` Francesco Dolcini
2022-12-02 17:20 ` Francesco Dolcini
2022-12-05 11:30 ` Francesco Dolcini
2022-12-05 11:30 ` Francesco Dolcini
2022-12-05 11:30 ` Francesco Dolcini
2022-12-05 15:28 ` Miquel Raynal
2022-12-05 15:28 ` Miquel Raynal
2022-12-05 15:28 ` Miquel Raynal
2022-12-02 16:45 ` Francesco Dolcini
2022-12-02 16:45 ` Francesco Dolcini
2022-12-02 16:45 ` Francesco Dolcini
2022-12-02 17:05 ` Miquel Raynal [this message]
2022-12-02 17:05 ` Miquel Raynal
2022-12-02 17:05 ` Miquel Raynal
2022-12-02 15:56 ` Thorsten Leemhuis
2022-12-02 15:56 ` Thorsten Leemhuis
2022-12-02 15:56 ` Thorsten Leemhuis
2022-12-04 12:50 ` Marek Vasut
2022-12-04 12:50 ` Marek Vasut
2022-12-04 12:50 ` Marek Vasut
2022-12-04 12:59 ` Thorsten Leemhuis
2022-12-04 12:59 ` Thorsten Leemhuis
2022-12-04 12:59 ` Thorsten Leemhuis
2022-12-04 15:50 ` Marek Vasut
2022-12-04 15:50 ` Marek Vasut
2022-12-04 15:50 ` Marek Vasut
2022-12-02 12:43 ` Greg KH
2022-12-02 12:43 ` Greg KH
2022-12-02 12:43 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221202180528.173ee343@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=francesco.dolcini@toradex.com \
--cc=francesco@dolcini.it \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=richard@nod.at \
--cc=shawnguo@kernel.org \
--cc=stable@vger.kernel.org \
--cc=u-boot@lists.denx.de \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.