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 X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED21FC433F5 for ; Wed, 22 Sep 2021 19:05:47 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 2A91A61153 for ; Wed, 22 Sep 2021 19:05:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2A91A61153 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nic.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 731D8832F4; Wed, 22 Sep 2021 21:05:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=nic.cz 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; secure) header.d=nic.cz header.i=@nic.cz header.b="dPlYeJAZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E544E832F4; Wed, 22 Sep 2021 21:05:43 +0200 (CEST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 75D73832F4 for ; Wed, 22 Sep 2021 21:05:39 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=nic.cz Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=marek.behun@nic.cz Received: from thinkpad (unknown [172.20.6.87]) by mail.nic.cz (Postfix) with ESMTPSA id AD397145BE0; Wed, 22 Sep 2021 21:05:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1632337538; bh=0R2igMfHPLvjiWWWnigC2UE8IteQ+nWPMGOTwZeqmAM=; h=Date:From:To; b=dPlYeJAZFI3iNNPKccC44y6zjNFA3vqPSb7K45bgRwcMteqiX7njCmxpxq2G4j2D5 7idzot0iGPeILIejrCXiNxlPjHoBvhIpDq1+qXyVUdKFz7mJqFrMzbEXPMUAMgAW6U P1tteizElIx3Nq1KBiu4MkrkBjvkMOEKRHaxpypA= Date: Wed, 22 Sep 2021 21:05:36 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Marek Vasut Cc: Patrick Delaunay , Tom Rini , u-boot@lists.denx.de, Pali =?UTF-8?B?Um9ow6Fy?= , Jagan Teki , Christophe KERELLO , Miquel Raynal , Priyanka Jain , Patrice Chotard , Heiko Schocher , Simon Glass , Vignesh R , U-Boot STM32 Subject: Re: [PATCH v4 0/2] mtd: spi: nor: force mtd name to "nor%d" Message-ID: <20210922210536.6c9c2f9e@thinkpad> In-Reply-To: References: <20210922162909.1857566-1-patrick.delaunay@foss.st.com> <20210922192925.723abcba@thinkpad> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.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.34 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.2 at phobos.denx.de X-Virus-Status: Clean On Wed, 22 Sep 2021 20:24:18 +0200 Marek Vasut wrote: > On 9/22/21 7:29 PM, Marek Beh=C3=BAn wrote: > > (Adding also Tom.) > >=20 > > Hi Patrick, Marek, > >=20 > > I find this either not complete or not needed: > >=20 > > - either you need mtd names to be of this format so that old MTDPARTS > > config definitions do not need to be changed, i.e. something like > > CONFIG_MTDPARTS_DEFAULT=3D"nor0:1M(u-boot),0x1000@0xfff000(env)" > > does not work currently, and you want to make it work. > >=20 > > I find your solution here incomplete because MTDPARTS can also be > > used to be passed to Linux as mtdparts parameter, but there is no > > guarantee that the "norN" numbering you are creating in U-Boot will > > be the same as the one in kernel. > >=20 > > - or it is not needed, because you can remove MTDPARTS definition from > > the board config entirely and move the information into device tree. > > In fact this was the main idea behind making the series > > Support SPI NORs and OF partitions in `mtd list` > > The SPI-NOR MTDs after this series can have conflicting names, > > because you can still choose between them via OF path with the `mtd` > > command. > >=20 > > Tom and I were of the opinion that MTDPARTS should be deprecated and > > removed in favor of OF. Marek Vasut says that this is not possible > > for every board, and so needs to stay. > >=20 > > BTW, I find it a little weird for Marek to defend old API which should > > be converted to DT, when in discussion about DM USB / Nokia N900 > > USB TTY console [1] he was defending the opinion that we should be > > heading to DT in U-Boot. > >=20 > > [1] > > https://patchwork.ozlabs.org/project/uboot/patch/20210618145724.2558-1-= pali@kernel.org/ =20 >=20 > That USB discussion is completely unrelated to the problem here, the USB= =20 > discussion is about internal (i.e. not user facing) conversion to DM/DT.= =20 > The user-facing ABI does not change there. Also, that discussion was=20 > about patching USB stack to permit new non-DM/DT operation, not fixing=20 > existing one. This is not only about the user ABI (altough now I agree that you are correct there, see below). What I meant is this: Should we push for converting to device-tree even if for some boards it is not possible, and would mean removing them? Because you are saying that MTDPARTS cannot be converted to DT for some boards. But N900 also cannot be reasonably converted because of space issues, as far as I understood. Yes, it has gigabytes of eMMC storage, and it was proposed to put SPL in MTD and U-Boot proper into eMMC on VFAT/ext4, but this simply cannot be done reasonably, because: - it would break Linux userspace (existing OS upgrade system would have to be rewritten and backwords compatibility would be broken) - it would make bootstrapping (booting newer version of U-Boot) while developing U-Boot a pain in the ass or maybe even impossible - I beleive there was some other reason Pali mentioned, but I cannot remember anymore > This problem here is user facing ABI, the mtdparts/mtdids. That user=20 > facing ABI got broken. Boards which do depend on it, even those=20 > currently in tree, are broken. Not all boards can update their=20 > environment, so some backward compatibility of the user facing ABI=20 > should be in place, even though it might not be to the degree Linux=20 > kernel does so. So far, it seems most of the U-Boot command line=20 > interface has managed to retain backward compatibility, I don't see why=20 > this here should be handled any differently. OK, I get that the if `mtd nor0` was working before, it should work also now. But the conversion from MTDPARTS to device tree could be probably done for lots of these, see below. > Note that there are not just a few boards that are broken, but hundreds.= =20 > I believe that itself justifies a fix, instead of just throwing all=20 > those hundreds of boards overboard. >=20 > u-boot$ git grep -l CONFIG_MTDIDS configs | wc -l > 203 Only 96 of those also grep the substring "nor". But okay, that is still a lot. The question is how many of them could be rewritten to DT: for cfg in $(git grep -l 'CONFIG_MTDIDS.*nor[0-9]' configs); do fgrep CONFIG_DEFAULT_DEVICE_TREE "$cfg" done | wc -l 92 of those 96 have CONFIG_DEFAULT_DEVICE_TREE defined. Of these, 65 contain CONFIG_DM_SPI_FLASH=3Dy, so at least these 65 could be converted. Of the rest 27, how many could also be converted to DM? How may use non-DM drivers? Marek