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 24C87C61DA4 for ; Mon, 6 Feb 2023 23:17:43 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 45EDB85348; Tue, 7 Feb 2023 00:17:41 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="GQgxmgQj"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E397E85237; Tue, 7 Feb 2023 00:17:39 +0100 (CET) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id BE90E8532D for ; Tue, 7 Feb 2023 00:17:36 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x82c.google.com with SMTP id f10so14927313qtv.1 for ; Mon, 06 Feb 2023 15:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=K65rRjAXLopgV+MeYNo6vLTUQgIQzdGhS/Q6FWKlTXc=; b=GQgxmgQjwoCHEjW+t6gbzfpX3JykZKUyoumnjsauCo6GDfWb3phxbxs32LnTy9mgK8 UyWKjX3wCvRQXZO+vKca+RqlmBPxtUCACk7xXLUo6ehzsTqw+7JdNmt4cKEZ9TvdYddK AgTpTL5fD67A8eKc4rVfNopo1WFZyU81T1+Rk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=K65rRjAXLopgV+MeYNo6vLTUQgIQzdGhS/Q6FWKlTXc=; b=IuJ0blNG9Y55Qhg3VbresWf73kPgOLY6HumqGycDZCpeBxeFDt1pTS0bla8CZIbP3O ZeFOsZJqhNSDF7piNtd199hOv+umwWp9rWZOx52WTu1DNreJ2NAPm5NosYP0MA2Xz4BF nIyapXu0WaAg/AoagrDI8SYcJzvHAk518n2OTzu3ClodcpCJ1pXDGASwkXBPLeBdgT9Q ZGvwi7X8hfnLNs1NxL4uWBnO5/DOr56COUzMwzmvECvd2rY6g9JkPlP/hh21X7gzEZWk UzbfhxFUGOLbbLUeYmxtOSQT+4WIpwwGgQkDvWToCTwEM3dFgYoPhuryR7rphlW9vq91 4neg== X-Gm-Message-State: AO0yUKX8UCKjjJpo3zw6KhawlKbAiGHltAcg/VyYqI2WMOw6lIVQXc+x DvGQTUme62wfIMr6d6kGTQPFIQ== X-Google-Smtp-Source: AK7set9QpOqe6+lNE44GA+trJZQPLF24AluXU9v7mL/RDoLezKQDxS5d7CiEWMgVQVkhZQtqwHqroA== X-Received: by 2002:a05:622a:151:b0:3b8:2a6c:d1e9 with SMTP id v17-20020a05622a015100b003b82a6cd1e9mr2102542qtw.18.1675725455408; Mon, 06 Feb 2023 15:17:35 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-7494-fb31-9b5f-683c.res6.spectrum.com. [2603:6081:7b00:6400:7494:fb31:9b5f:683c]) by smtp.gmail.com with ESMTPSA id f18-20020a05620a20d200b007090f7a4f2asm8254058qka.82.2023.02.06.15.17.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Feb 2023 15:17:34 -0800 (PST) Date: Mon, 6 Feb 2023 18:17:31 -0500 From: Tom Rini To: Francesco Dolcini Cc: Simon Glass , u-boot@lists.denx.de, Marcel Ziswiler , Francesco Dolcini , Marek Vasut , Miquel Raynal , Nikita Kiryanov , Tim Harvey , Javier =?iso-8859-1?Q?Mart=EDnez?= Canillas , Enric Balletbo i Serra , Niel Fourie , Parthiban Nallathambi , Patrick Delaunay , Patrice Chotard , uboot-stm32@st-md-mailman.stormreply.com Subject: Re: [PATCH v2 1/3] fdt: validate/fix cells count on mtdpart fixup Message-ID: References: <20230206224838.75963-1-francesco@dolcini.it> <20230206224838.75963-2-francesco@dolcini.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i4xpTqD6yhhDBlAr" Content-Disposition: inline In-Reply-To: <20230206224838.75963-2-francesco@dolcini.it> X-Clacks-Overhead: GNU Terry Pratchett 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 --i4xpTqD6yhhDBlAr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 06, 2023 at 11:48:36PM +0100, Francesco Dolcini wrote: > From: Francesco Dolcini >=20 > Fixup #size-cells value when updating the MTD partitions, this is > required to prevent issues in case the MTD parent set #size-cells to > zero. > This could happen for example in the legacy case in which the partitions > are created as direct child of the mtd node and that specific node has > no children. Recent clean-up on Linux device tree files created a boot > regression on colibri-imx7 [0]. >=20 > This fixup has the limitation to assume 32-bit (#size-cells=3D1) > addressing, therefore it will not work with device bigger than 4GiB. >=20 > This change also enforce #address-cells to be the same as #size-cells, > this was already silently enforced by fdt_node_set_part_info(), now this > is checked explicitly and partition fixup will just fail in such case. >=20 > When the partition list is static the preferred way to pass the mtd > partition list to the kernel is to either define those in the source DTS > file or use mtdparts=3D in the command line. > Tweaking the DT from U-Boot should be avoided, unless some dynamic > changes are required, since it proved to be problematic when not > following the evolution of the "standard". >=20 > Link: https://lore.kernel.org/all/Y4dgBTGNWpM6SQXI@francesco-nb.int.torad= ex.com/ > Link: https://lore.kernel.org/all/20221202071900.1143950-1-francesco@dolc= ini.it/ > Cc: Marek Vasut > Cc: Miquel Raynal > Signed-off-by: Francesco Dolcini > --- > v2: improved commit message > --- > common/fdt_support.c | 45 ++++++++++++++++++++++++++++++++++---------- > 1 file changed, 35 insertions(+), 10 deletions(-) I'm dropping the linux-mtd list here and adding a bunch more platform maintainers. In general, calling fdt_fixup_mtdparts is the wrong choice. I see we do have a few cases in U-Boot where we're clearly doing something dynamic to the partition table, but it looks like at first glance most callers are using this hook when they should either be having the partition map in the device tree properly (and using one of the appropriate bindings) or passing the map in via the kernel command line. I would like to ask everyone I've added to the list here to please audit your platform and update it as needed. Thanks! --=20 Tom --i4xpTqD6yhhDBlAr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmPhioUACgkQFHw5/5Y0 tyweUQv/Shsskc3X1H5wB3PLofkjI4t6t8/lsreth8c5MCYSNPJGjgnrf7BxB01G HOx4A9vIIgwmpue2ObwD8hpSMOz4uLnOYCwOvjnAcc8KXxWwQyrMG/NTLCtY7ebg vg+3BZazqYRe//oOAM3hSF6cgngI0Y2E4GTvJH/Zzy2KR4sF1pqRjI7eTOdLUhUU WKeHNbyXDoajg5Utz6o6lJLWnFMyO666dRL5Pi9TirlLdWVWrniiMQO5PulU4Xuj Zt5FXpqrAUY1ttx7cm5ZAcBVY8lKmEK8pIPZEAN0VemxnXMbvzSbInJsEkPAEwTb xULpFY64js9gwQnl5v7xi9Zg6DP+VvteaRkRMUGU/m1jhJ4Vnc4KPuXbbTg4TZpO MQNgVWgaoduXZiQ5XLeJE1EWr/qS3C9P5MlR2fHk2Iknwmdgi60ybz5FAxpu3KTS 64A+TtM988j/ixNzKKQCnXc7IT3By+PWmmu7luSoMv267wjiCgbkp3JVUzC2WXo6 g4lah0Gd =fq94 -----END PGP SIGNATURE----- --i4xpTqD6yhhDBlAr--