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 67D21C4321E for ; Mon, 5 Dec 2022 11:26:59 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DE0708547B; Mon, 5 Dec 2022 12:26:56 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=dolcini.it Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=mailserver.it header.i=@mailserver.it header.b="fJSptKx3"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4D8E7854C1; Mon, 5 Dec 2022 12:26:55 +0100 (CET) Received: from smtp-out-07.comm2000.it (smtp-out-07.comm2000.it [212.97.32.77]) (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 CB5638547B for ; Mon, 5 Dec 2022 12:26:52 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=dolcini.it Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=francesco@dolcini.it Received: from francesco-nb.int.toradex.com (31-10-206-125.static.upc.ch [31.10.206.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: francesco@dolcini.it) by smtp-out-07.comm2000.it (Postfix) with ESMTPSA id 04B633C2104; Mon, 5 Dec 2022 12:26:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailserver.it; s=mailsrv; t=1670239612; bh=T5iUgqLM5/wTl1bWy1r9VQ72eZ+xJCXi7OjAOJZLSnE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=fJSptKx3by6D7wAt+PgUu1Zi/Hmuo16Cpn5Yr8io+VGfuAVwzAxZ3fGCeG+XscN4U KVBM+qNDjWoBjjF9BOpXet8hlQmnV3l9Q1umhpFEYiY8BLeON7xn99fJAjjOrIK7dB JaE8o5dYiAddCRYqUi2N1a7YwNgChD5ANyk6yshdjpRZgSMjgRw1iI8xZl/50U4XD9 IA1nHrULn1lUHlqdlTzXkhhc8zC9Y5i1OrsXS3dwvyeDUk016Zm6UUzegTH2lGFPnP tD7swS4nDZHnyb8SjSJxhAJoHjr3X49unF7SbXOYKS8L+h2jgnFQDUVNyKUHbrcIRL VVtdZoIFqidRA== Date: Mon, 5 Dec 2022 12:26:44 +0100 From: Francesco Dolcini To: Marek Vasut , Miquel Raynal Cc: Francesco Dolcini , 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: References: <20221202150556.14c5ae43@xps-13> <2b6fc52d-60b9-d0f4-ab91-4cf7a8095999@denx.de> <20221202160030.1b8d0b8a@xps-13> <223b7a4e-3aff-8070-7387-c77d2ded1dd6@denx.de> <20221202164904.08d750df@xps-13> <0503c46d-c385-74f5-f762-51d87a5ebaff@denx.de> <20221202174255.2c1cb2ff@xps-13> <20221202175730.231d75d5@xps-13> <7afd364c-33b8-38a9-65a6-015b4360db6b@denx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7afd364c-33b8-38a9-65a6-015b4360db6b@denx.de> 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 On Fri, Dec 02, 2022 at 06:08:22PM +0100, Marek Vasut wrote: > But here I would say this is a firmware bug and it might have to be handled > like a firmware bug, i.e. with fixup in the partition parser. I seem to be > changing my opinion here again. I was thinking at this over the weekend, and I came to the following ideas: - we need some improvement on the fixup we already have in the partition parser. We cannot ignore the fdt produced by U-Boot - as bad as it is. - the proposed fixup is fine for the immediate need, but it is not going to be enough to cover the general issue with the U-Boot generated partitions. U-Boot might keep generating partitions as direct child of the nand controller even when a partitions{} node is available. In this case the current parser just fails since it looks only into it and it will find it empty. - the current U-Boot only handle partitions{} as a direct child of the nand-controller, the nand-chip is ignored. This is not the way it is supposed to work. U-Boot code would need to be improved. With all of that said I think that Miquel is right > When a patch breaks a board and there is no straight fix, you revert > it, then you think harder. That's what I am saying. This is a temporary > solution. ? Francesco