linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 5 Dec 2022 16:28:44 +0100	[thread overview]
Message-ID: <20221205162844.5dc28b8b@xps-13> (raw)
In-Reply-To: <Y43WSCsvfnfbcMPQ@francesco-nb.int.toradex.com>

Hi Francesco,

francesco@dolcini.it wrote on Mon, 5 Dec 2022 12:30:16 +0100:

> Hello Miquel
> 
> On Fri, Dec 02, 2022 at 06:20:02PM +0100, Francesco Dolcini wrote:
> > On Fri, Dec 02, 2022 at 05:42:55PM +0100, Miquel Raynal wrote:  
> > > Please also do it with the NAND chip described. If, when the NAND chip
> > > is described U-Boot tries to create partitions in the controller node,
> > > then the situation is even worse than I thought. But I believe  
> > 
> > It's like that for U-Boot older than v2022.04 ... and IMO we cannot
> > ignore it.
> > 
> > Said that from the code U-Boot looks into a `partition{}` node only as a
> > direct child of the nand-controller, if there is a nand-chip in between
> > the nand-controller{} and the partitions{} it will just ignore it.
> > 
> > I could try to see what it is doing exactly, but I would need a little
> > bit more time, I just tried changing the DTS as wrote I got a non
> > bootable system.  
> 
> If I have a nand-chip { partitions {} } described in the dts U-Boot
> (even the latest one) ignores it and generates the partition as child of
> the nand controller, the linux parser however see that partitions{}
> exists, even if empty, and ignore the partition directly defined as
> child of the nand controller.
> 
> TL;DR: parser fails and boot fails according to that.

Yeah I get that. For me the longterm goal should be to just kill that
function. We have proper DT support today, Linux knows how to read the
mtdparts cmdline variable, so there is no need for anything else. I
guess in U-Boot we should just:
- warn users of this function that the function is deprecated and they
  should update their machine support
- just migrate to another solution on the colibri board

What do you think?

Thanks,
Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-12-05 15:30 UTC|newest]

Thread overview: 48+ 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  9:14 ` Miquel Raynal
2022-12-02 10:12   ` Francesco Dolcini
2022-12-02 10:24     ` Francesco Dolcini
2022-12-02 10:53       ` Miquel Raynal
2022-12-02 11:23         ` Francesco Dolcini
2022-12-02 14:05           ` Miquel Raynal
2022-12-02 14:31             ` Marek Vasut
2022-12-02 15:00               ` Miquel Raynal
2022-12-02 15:23                 ` Marek Vasut
2022-12-02 15:49                   ` Miquel Raynal
2022-12-02 16:01                     ` Miquel Raynal
2022-12-02 16:17                     ` Marek Vasut
2022-12-02 16:42                       ` Miquel Raynal
2022-12-02 16:52                         ` Marek Vasut
2022-12-02 16:57                           ` Miquel Raynal
2022-12-02 17:08                             ` Marek Vasut
2022-12-05 11:26                               ` Francesco Dolcini
2022-12-05 13:49                                 ` Miquel Raynal
2022-12-05 16:25                                   ` Marek Vasut
2022-12-15  7:16                                     ` Miquel Raynal
2022-12-15  7:45                                       ` Marek Vasut
2022-12-15  8:04                                         ` Miquel Raynal
2022-12-16  0:36                                           ` Marek Vasut
2022-12-16  7:52                                             ` Francesco Dolcini
2022-12-16  7:45                                       ` Francesco Dolcini
2022-12-16 10:46                                         ` Marek Vasut
2022-12-16 11:01                                           ` Miquel Raynal
2022-12-16 12:37                                             ` Francesco Dolcini
2022-12-16 13:37                                               ` Miquel Raynal
2022-12-16 14:32                                                 ` Marek Vasut
2022-12-16 15:35                                                   ` Miquel Raynal
2022-12-16 16:30                                                     ` Francesco Dolcini
2023-01-02  9:40                                                       ` Miquel Raynal
2023-01-05 11:33                                                         ` Miquel Raynal
2023-01-05 12:47                                                           ` Francesco Dolcini
2023-01-05 14:51                                                             ` Marek Vasut
2023-01-05 15:03                                                               ` Miquel Raynal
2022-12-02 17:20                         ` Francesco Dolcini
2022-12-05 11:30                           ` Francesco Dolcini
2022-12-05 15:28                             ` Miquel Raynal [this message]
2022-12-02 16:45                       ` Francesco Dolcini
2022-12-02 17:05                         ` Miquel Raynal
2022-12-02 15:56               ` Thorsten Leemhuis
2022-12-04 12:50                 ` Marek Vasut
2022-12-04 12:59                   ` Thorsten Leemhuis
2022-12-04 15:50                     ` Marek Vasut
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=20221205162844.5dc28b8b@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).