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 61726C3DA7A for ; Mon, 2 Jan 2023 09:40:18 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4234B85515; Mon, 2 Jan 2023 10:40:15 +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="H4c1yh/V"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 299CD85282; Mon, 2 Jan 2023 10:40:13 +0100 (CET) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) (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 52B17854D0 for ; Mon, 2 Jan 2023 10:40:07 +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 4B6C6240009; Mon, 2 Jan 2023 09:40:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1672652406; 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=5E6lCTS2ynO3kNOr2DrozkQ00vp5/Kkw0BvSXENsHXY=; b=H4c1yh/VB54M+SKD9HDIZAF63eVXa2yhH6f6CxSWCVqlmzIWxOgkzo+mKG7usBZesd4axd q8cwWe5EB8lRIlWHxMOoZLRHic6sLONpwflfrR7ksq6/5TeWBsqqjNz0H/oIzhiUXlC2Xr /gQni3u+Mvg0qvh4LVdTOQi9XVxmFN1QgL3tWhGTI+60xdbq2xJqkzKKohLpJfgvZ3ueGl 6mQ7NEKtYXhlViLCJhIXm96QQ7ZwGbaPRLTOBY6/z8PZXWgEMhBCtC6YBCjLLq3U+pvIZa TZWEW9T/0v9VEixvNZaL6G2IHHBOGAtOAez+WSlNcM6EVnmyNUNDiDgCnQbolw== Date: Mon, 2 Jan 2023 10:40:04 +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: <20230102104004.6abae6da@xps-13> In-Reply-To: References: <6f5f5b32-d7fe-13cc-b52d-83a27bd9f53e@denx.de> <20221216120155.4b78e5cf@xps-13> <20221216143720.3c8923d8@xps-13> <20221216163501.1c2ace21@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, 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: =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? 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. >=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] 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. Thanks, Miqu=C3=A8l