Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0

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: Thu, 5 Jan 2023 12:33:34 +0100	[thread overview]
Message-ID: <20230105123334.7f90c289@xps-13> (raw)
In-Reply-To: <20230102104004.6abae6da@xps-13>

Hi Francesco,

miquel.raynal@bootlin.com wrote on Mon, 2 Jan 2023 10:40:04 +0100:

> Hi Francesco,
> 
> francesco@dolcini.it wrote on Fri, 16 Dec 2022 17:30:18 +0100:
> 
> > On Fri, Dec 16, 2022 at 04:35:01PM +0100, Miquel Raynal wrote:  
> > > marex@denx.de wrote on Fri, 16 Dec 2022 15:32:28 +0100:    
> > > > The second part of the message, as far as I understand it, is
> > > > "ignore problems this will cause to users of boards we do not know
> > > > about, let them run into unbootable systems after some linux kernel
> > > > update,     
> > > 
> > > Now you know what kernel update will break them, so you can prevent it
> > > from happening. 
> > > 
> > > For boards without even a dtsi in the kernel, should we care?    
> > 
> > Would caring for those boards not be just exact the same as caring for
> > some UEFI/ACPI mess for which no source code is normally available and
> > nobody really known at which point the various vendors have forked their
> > source code from some Intel or AMD or whatever reference code?  
> 
> I am sorry I don't know UEFI/ACPI well enough to discuss it.
> 
> > IMHO we should care for the multiple reason I have already written in my
> > previous emails.
> > 
> > And honestly, just as a side comment, I would feel way more happy
> > to know that the elevator control system in the elevator I use everyday
> > or the chemical industrial plan HMI next to my home is running an up to
> > date Linux system that is not affected by known security vulnerabilities
> > and they did stop updating it just because there was some random bug
> > preventing the updated kernel to boot and nobody had the time/skill to
> > investigate and fix it. [1]  
> 
> The issue comes from a very specific U-Boot function that should have
> never existed. I hope people working on chemical plants do not make
> use of these and will not disregard the "your DT is broken there [...]"
> warning we plan to add right before their updated board will fail. We
> are not living people in the dark, I agreed for a warning, but I don't
> think applying the proposed fix blindly is wise and future-proof.

Let's move forward with this. Let's assume my fears are baseless. We
might consider the situation where someone tries to hide the partitions
by setting #size-cell to 0 even wronger and too unlikely. Hopefully we
will not break any other existing setups by applying an always-on fix.

I would still like to see U-Boot partitions handling evolve, at least:
- fix #size-cells in fdt_fixup_mtd()
- avoid the fdt_fixup_mtd() call from Collibri boards (ie. an example
  that can be followed by the other users)

On Linux side let's fix #size-cells like you proposed without filtering
against a list of compatibles. We however need to improve the
heuristics:
- Do it only when there are partitions declared within a NAND
  controller node.
- Change the warning to avoid mentioning backward compatibility, just
  mention this is utterly wrong and thus the value will be set to 1
  instead of 0.
- Mention in the comment above this only works on systems with <4GiB
  chips.
If you think about other conditions please feel free to add them.

Do you concur?

Thanks,
Miquèl

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