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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8075C433EF for ; Sat, 25 Sep 2021 03:06:34 +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 77968604DA for ; Sat, 25 Sep 2021 03:06:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 77968604DA 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 342E7834E3; Sat, 25 Sep 2021 05:06:31 +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=1632539191; bh=+t3epBFcFyDRFYnBZhiqZ9X75eYM8AwMF71peHe5z+M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=PKXsQKS+T9iuMwvef3eWr3R5FYjzK9wbV2gGsFgBljXx54hB0v4rvL43FCJYxL7ab INQZ0wYM1UzT2eqwg2pBrtNG3m8JaXENSGCngPSOICHfDH4VLsvoKpYVnQcw/4nD3n U44IEx7oz/cfl89Yfnv+vjzi5F7uPGsSJP+nAjmo8T80M+EKbOYOX6m4KDO9Wg31jf wsGvLiD35NTReI/Ml7DWm7lZJ/Gs3brQqCUL6FD/z+nt6EC2CGvdyCsFDXVYOGpERK KKhIclq/dtk/DQ74sskBOM9RfKJ3cK3IjzugOdJa4xPiF2brZwkZYfmKLhWsCt0rvE daRKFIqdOQDuQ== 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 AE4BD834E0; Sat, 25 Sep 2021 05:06:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1632539188; bh=+t3epBFcFyDRFYnBZhiqZ9X75eYM8AwMF71peHe5z+M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=iPp0BlRri8hPSwzGrGmOADwO/AaXl6fvUe3pBe7dochmoAgvwBJWooPzCIf2MXCqO aSVjeLmjZ8KvIMM3JqtZNOJiTweR0u+m3a+A+pwnRvgKvxhPlQ6kdK08cyQH5pF0VK 4oePE7lqokjljNd+Ma3UN2JKmlmLMA+Zdeq6b2FEB8uDfNFEP6Le6E3wbfesZUSiuj BywEUZqm8+1m0nkmkV7xw/GK0oNntylOJMo57FkmyXsOdlIxcqYH1Ea0MdTGbBRbj4 FiHAiHkQhkajf1xOQ6HDIR44eLlOjln70ScXuzvkb7E/6313ui5fSdhLYHC54RllZC ZlRzAaI3g69EQ== Subject: Re: [PATCH v4 0/2] mtd: spi: nor: force mtd name to "nor%d" To: =?UTF-8?Q?Marek_Beh=c3=ban?= , Tom Rini 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> <56df80f7-aa1d-3cff-5b29-16fdafcf7bcf@denx.de> <20210922194615.GD31748@bill-the-cat> <59ce8fa7-64f2-07c9-ee2b-4b59335b3907@denx.de> <20210922200053.GE31748@bill-the-cat> <4f1609c3-0aca-3f49-715b-95c8a3336f61@foss.st.com> <20210924182257.GG31748@bill-the-cat> <20210924212559.22006a61@thinkpad> <20210925021200.7d5b62e2@thinkpad> From: Marek Vasut Message-ID: Date: Sat, 25 Sep 2021 05:06:27 +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: <20210925021200.7d5b62e2@thinkpad> Content-Type: text/plain; charset=utf-8; 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/25/21 2:12 AM, Marek Behún wrote: > On Fri, 24 Sep 2021 22:09:15 +0200 > Marek Vasut wrote: > >> I have a feeling the discussion is again banking toward "mtdparts" and >> "DT", which really is a solved problem, or at least we agreed upon the >> solution. > > I was trying to explain to Patrick how he can convert the ST board so > that the mtd partitions will be defined in DT and board code won't need > mtdids if he also converts to distro boot correctly. > >> The patch is trying to fix MTDIDS and their look up in >> get_mtd_device_nm(). This is all U-Boot stuff, it has nothing to do with >> passing mtd partitions to Linux at all. > > The solution here is to get rid of MTDIDS also. But I guess this will > take some time, so it does make sense for get_mtd_device_nm() to > return the same device as previously when given argument "norN". I'd say MTDIDS is user ABI, so we shouldn't break it until there is clear way forward. (yes, I agree with pretty much all you are saying, I just want to make this clear) > The reason why I put SPI NOR name into mtd->name was because otherwise > the `mtd list` command did not print that name anywhere (since it > doesn't know how, because that SPI-NOR data are private for the > jedec_spi_nor driver). > > Since > - every mtd device has mtd->type, for NOR flash this is MTD_NORFLASH > - we can iterate mtd devices in order they were registered > (mtd_for_each_device does this) > we can easily implement a function > get_mtd_device_by_type_and_id() No, we cannot. We have to make sure the Parallel NORs go first, SPI NORs second, otherwise we break the old ABI. That's what Patrick is valiantly battling here. > that, when given string "norN" will find the N-th mtd device of type > MTD_NORFLASH. > > This function could than be called from get_mtd_device_nm() if > everything failed, or in some other way. > > Tom, Marek, Patrick, what do you think? Maybe we should go with a simpler counting approach first (at least for this release) and then improve on that ? That would give us some time to think the solution through ... at which point I wouldn't even be opposed to passing full DT path to ubi part, something like: ubi part /soc/controller@0x1234/flash@0/partition@1 or something like that. The above is always stable and unique because it is hardware path, it does get flushed right down to get_mtd_device_nm(), and it basically skips MTDIDS. With DT aliases you can probably write some shorthand for a long HW path.