From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 655B8C3DA7A for ; Thu, 5 Jan 2023 11:33:47 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1C12C851DF; Thu, 5 Jan 2023 12:33:45 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.b="E98RZEZi"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id CA7728500F; Thu, 5 Jan 2023 12:33:42 +0100 (CET) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 224B5851DF for ; Thu, 5 Jan 2023 12:33:39 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=miquel.raynal@bootlin.com Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 115D520010; Thu, 5 Jan 2023 11:33:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1672918418; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=czix4WDiCzpW3gGaXbhaVHkR8drxG1fsG3atEPzhoE8=; b=E98RZEZil+eOZnuosJNaIyf29QcPtWzut/isscPsVXu2r8jb+ceMRofLb2GJg9QwFchFCe Ri9pjxxDF568W8/pTwqkmArc4ylao8PityZ+Fo3jU0R/aOhIDWTkHqw+CZluG6+vaHftRx NTkfyrFPC15rbjBWQTnIN/aK9US9TJam8c5JEM0WANz8zSqnOx4RnUptxqwmjOC6dR+b/G KhtwNSsMZKa7aYoCUcGUoZc60wSBB+QPVLTU8AcXEQrkCldRFlrUoDZuDrdLdSx/xNyodI w8J7rIwdP6gSmXCUITvKx2Mn4LgWuyI0dPGrCkejB10l7RrbYPvi+K/mSphrTQ== Date: Thu, 5 Jan 2023 12:33:34 +0100 From: Miquel Raynal To: Francesco Dolcini Cc: Marek Vasut , Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, Francesco Dolcini , Shawn Guo , 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 Message-ID: <20230105123334.7f90c289@xps-13> In-Reply-To: <20230102104004.6abae6da@xps-13> References: <6f5f5b32-d7fe-13cc-b52d-83a27bd9f53e@denx.de> <20221216120155.4b78e5cf@xps-13> <20221216143720.3c8923d8@xps-13> <20221216163501.1c2ace21@xps-13> <20230102104004.6abae6da@xps-13> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi Francesco, miquel.raynal@bootlin.com wrote on Mon, 2 Jan 2023 10:40:04 +0100: > Hi Francesco, >=20 > francesco@dolcini.it wrote on Fri, 16 Dec 2022 17:30:18 +0100: >=20 > > On Fri, Dec 16, 2022 at 04:35:01PM +0100, Miquel Raynal wrote: =20 > > > marex@denx.de wrote on Fri, 16 Dec 2022 15:32:28 +0100: =20 > > > > 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, =20 > > >=20 > > > Now you know what kernel update will break them, so you can prevent it > > > from happening.=20 > > >=20 > > > For boards without even a dtsi in the kernel, should we care? =20 > >=20 > > 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? =20 >=20 > I am sorry I don't know UEFI/ACPI well enough to discuss it. >=20 > > IMHO we should care for the multiple reason I have already written in my > > previous emails. > >=20 > > 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] =20 >=20 > 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=C3=A8l