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, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 6162DC433F5 for ; Wed, 22 Sep 2021 19:39:30 +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 D187161100 for ; Wed, 22 Sep 2021 19:39:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D187161100 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de 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 CD19B83314; Wed, 22 Sep 2021 21:39:27 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1632339568; bh=65Iyl98ZMw+bGGGyuiYCvVunJnQh+L1B1hwDiDX4MDA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=X8PX8Ry6RSeEgpRchTz9ri0P+itdYpSRuIN9kQdP/nWtJ9m8v2etPQARGNczBBPJM X8yUxxrzeIch6arxLZdrppd0UUtZrxxWNEZyIpvDm1Q6Vo777+u3iI2N/9qux1DtKA rIEM1QQ2Y2qkj9rNCrxVDn+JcLs8Rh9FF4O62fluSJzqJlpyz+I3NWJVjhrZchwrBU olooPH7qtFipmHd8n5LN/nhrLI2h2rvH9erqzV8R8TuiOQHvsp2gSdDuumcCSiQIVB cHgUqmW3YFpUZxdy+qcWitT9UljfFSqzitMzfSoLRq3Xoq2gjfey4eBSb3f1RMs7KL JKBvHiNQ9Qnaw== Received: from [IPv6:::1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 091878332C; Wed, 22 Sep 2021 21:39:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1632339565; bh=65Iyl98ZMw+bGGGyuiYCvVunJnQh+L1B1hwDiDX4MDA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=e2rLROJ5Uw+pCXjm0YtRCXqK0lfuiPO2t0dalA/HAg0zhngznDuI3ta7i/woXlktF teHZKbvRcwV6pqf7KLdSc4VUbMKdQEiTcQ581EG4PaC7R9efN6PnyYc9l+doFjHNw/ wW87P1Ix7P6096EaSnVDEJgilSNzHPXCOXBagejihaB82meP3qxd3qtzM3/9m9X5of XYZWOMjS/Iz0WqMtsq4yueNrchZUcNngP2/himGoUXa6I0K9xmS/YaNARGZfuZsvqc DNtv/lPbMlbJ9OUMim8Yu+9O9QLJvgLpqYvyFUYltiSXiZqdgULJl4p3ld4Sm16Sz7 /Y7CmYMALfX8w== Subject: Re: [PATCH v4 0/2] mtd: spi: nor: force mtd name to "nor%d" To: Tom Rini , =?UTF-8?Q?Marek_Beh=c3=ban?= Cc: Patrick Delaunay , u-boot@lists.denx.de, =?UTF-8?Q?Pali_Roh=c3=a1r?= , Jagan Teki , Christophe KERELLO , Miquel Raynal , Priyanka Jain , Patrice Chotard , Heiko Schocher , Simon Glass , Vignesh R , U-Boot STM32 References: <20210922162909.1857566-1-patrick.delaunay@foss.st.com> <20210922192925.723abcba@thinkpad> <20210922210536.6c9c2f9e@thinkpad> <20210922192337.GA31748@bill-the-cat> From: Marek Vasut Message-ID: <60258ab6-d5ef-4ecd-0dd3-ff8c5b355c14@denx.de> Date: Wed, 22 Sep 2021 21:39:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20210922192337.GA31748@bill-the-cat> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 9/22/21 9:23 PM, Tom Rini wrote: > On Wed, Sep 22, 2021 at 09:05:36PM +0200, Marek Behún wrote: >> On Wed, 22 Sep 2021 20:24:18 +0200 >> Marek Vasut wrote: >> >>> On 9/22/21 7:29 PM, Marek Behún wrote: >>>> (Adding also Tom.) >>>> >>>> Hi Patrick, Marek, >>>> >>>> I find this either not complete or not needed: >>>> >>>> - 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="nor0:1M(u-boot),0x1000@0xfff000(env)" >>>> does not work currently, and you want to make it work. >>>> >>>> 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. >>>> >>>> - 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. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> [1] >>>> https://patchwork.ozlabs.org/project/uboot/patch/20210618145724.2558-1-pali@kernel.org/ >>> >>> That USB discussion is completely unrelated to the problem here, the USB >>> discussion is about internal (i.e. not user facing) conversion to DM/DT. >>> The user-facing ABI does not change there. Also, that discussion was >>> about patching USB stack to permit new non-DM/DT operation, not fixing >>> 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 >>> facing ABI got broken. Boards which do depend on it, even those >>> currently in tree, are broken. Not all boards can update their >>> environment, so some backward compatibility of the user facing ABI >>> should be in place, even though it might not be to the degree Linux >>> kernel does so. So far, it seems most of the U-Boot command line >>> interface has managed to retain backward compatibility, I don't see why >>> 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. >>> I believe that itself justifies a fix, instead of just throwing all >>> those hundreds of boards overboard. >>> >>> 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=y, 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? > > I was thinking maybe we have problems with the platforms that "mtdparts > default", of which we have a handful and most of that handful also do it > to then make use of the partition table within U-Boot (dfu, or update > the on-flash U-Boot). Of those, it might make most sense to poke the > maintainer directly on how to proceed. I have a feeling you are talking about a different problem here. What is broken is U-Boot only look up of MTD device from which to attach e.g. UBI or jffs2. That's MTDIDS. There you have that nor0 stuff, see: cmd/jffs2.c: * mtdids=nor0=edb7312-nor,nand0=edb7312-nand That is what currently does not work in U-Boot, it has nothing to do with Linux.