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.2 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,URIBL_BLOCKED,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 5FB0BC4338F for ; Thu, 22 Jul 2021 20:45:16 +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 8686F60EB2 for ; Thu, 22 Jul 2021 20:45:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8686F60EB2 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 7FE3B82C44; Thu, 22 Jul 2021 22:45:08 +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="kWxIBuue"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A6DE480223; Thu, 22 Jul 2021 22:45:06 +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 F17B980223 for ; Thu, 22 Jul 2021 22:45:00 +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 4F3B314001D; Thu, 22 Jul 2021 22:45:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1626986700; bh=qfzCcNRHJFGv3TR0uc5AQgxu17FkGvZt+1Ttk9MegJw=; h=Date:From:To; b=kWxIBuuec9GWZd7fTaHQ7OILEXElWDpPzNqCzUUI/nX501oSQ8MkJUoLzLZJN3HMr wHSVZNQhBv4Teq9yXHoTFYkRxzde4YX4R8hweN18B0Fwwnb7XsIfzVB03QW1QmfAe3 aewaE9oqaKaUy2FInde8Yhw8Z00g283g/0/m43fc= Date: Thu, 22 Jul 2021 22:44:59 +0200 From: Marek Behun To: Jagan Teki Cc: Masami Hiramatsu , Simon Glass , Miquel Raynal , Tom Rini , U-Boot-Denx , Patrice Chotard , Patrick Delaunay , Heiko Schocher , Pali =?UTF-8?B?Um9ow6Fy?= Subject: Re: [PATCH RESEND u-boot-spi 0/8] Fix `mtd erase` when used with mtdpart Message-ID: <20210722224459.3bdacfb2@thinkpad> In-Reply-To: References: <20210714235109.25228-1-marek.behun@nic.cz> X-Mailer: Claws Mail 3.17.8 (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, 21 Jul 2021 21:46:56 +0530 Jagan Teki wrote: > Hi Marek, >=20 > On Thu, Jul 15, 2021 at 5:21 AM Marek Beh=C3=BAn wro= te: > > > > Hello, > > > > I accidentally forgot to send this series to U-Boot's mailing list last > > time, meaning it did not end up in patchwork, so now I am resending it. > > Sorry for this mess. > > > > The original cover letter said: > > > > this patch series fixes the `mtd erase` command when used with mtdpart > > with a partition of non-zero offset. > > > > Currently when the `mtd erase` command is used for such a partition, > > it does not erase all blocks. Instead after a block is erased, the next > > block address not current block address + block size, but current block > > address + block size + partition offset, due to spi_nor_erase() not > > calling mtd_erase_callback(): =20 > > =3D> mtd erase "Rescue system" =20 > > Erasing 0x00000000 ... 0x006fffff (1792 eraseblock(s)) > > jedec_spi_nor spi-nor@0: at 0x100000, len 4096 > > jedec_spi_nor spi-nor@0: at 0x201000, len 4096 > > jedec_spi_nor spi-nor@0: at 0x302000, len 4096 > > jedec_spi_nor spi-nor@0: at 0x403000, len 4096 > > jedec_spi_nor spi-nor@0: at 0x504000, len 4096 > > jedec_spi_nor spi-nor@0: at 0x605000, len 4096 > > jedec_spi_nor spi-nor@0: at 0x706000, len 4096 > > > > This series adds some fixes to spi_nor_erase() function, then adds > > calling of mtd_erase_callback() to fix this bug. > > > > The series also contains an improvement - adding the posibility to > > interrupt spi_nor_erase() with Ctrl+C; and another one - making mtdpart= 's > > _erase() method more sane so that the above mentioned bug will not occur > > even if underlying driver does not call mtd_erase_callback(). > > > > Moreover I would also like to start a discussion regarding the MTD > > subsystem: > > - U-Boot's MTD subsystem is based on Linux's, with many #ifdef __U_BOOT= __ > > macros > > - this was done to make it easier to port Linux's patches to U-Boot > > - the problem is that it seems nobody did port Linux's MTD patches to > > U-Boot for a long time, the code is many times different from Linux', > > and it would be very hard to align it > > - therefore I propose to get rid of all the #ifdefs, remove the Linux > > specific code, and continue developing the code independently from > > Linux. This would make it impossible to apply Linux patches in some > > kind of automatic way, but this is currently already impossible > > anyway > > What do you guys think? > > > > Marek > > > > Marek Beh=C3=BAn (8): > > mtd: spi-nor-core: Try cleaning up in case writing BAR failed > > mtd: spi-nor-core: Check return value of write_enable() in > > spi_nor_erase() > > mtd: spi-nor-core: Don't overwrite return value if it is non-zero > > mtd: spi-nor-core: Check return value of write_disable() in > > spi_nor_erase() > > mtd: spi-nor-core: Don't check for zero length in spi_nor_erase() > > mtd: spi-nor-core: Call mtd_erase_callback() from spi_nor_erase() > > mtd: spi-nor-core: Check for ctrlc() in spi_nor_erase() > > mtd: mtdpart: Make mtdpart's _erase method sane =20 >=20 > Found the build error with CI [1], would you please check? >=20 > [1] https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/8345 >=20 > Jagan. Jagan, I am unable to get the output of the failed CI tests. Probably because I do not have an account at source.denx.de. I tried to run "sandbox with clang" CI scenario on my local machine and it is successful. Can you send me outputs of the failed scenarios? Marek