Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2810112ybk; Mon, 18 May 2020 08:26:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyVPX72r3OV4FMfZhJa2/HZ8HvM+vR65XkkcNv6pUwLXhEuYHfvmWr3Ql9xWWe5m5EBP0KR X-Received: by 2002:a05:6402:1cb6:: with SMTP id cz22mr13307831edb.86.1589815603205; Mon, 18 May 2020 08:26:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589815603; cv=none; d=google.com; s=arc-20160816; b=RXODiSFDon6s9LlDJ1u/3Y/v0QCWW41Irz5Y0Z+U4u70nLMdFJvi4GD7rXy514BobN UL13By8zCKyojrMVXZuYBrMW7XGhfY/MIBOazQNkYRq0+2CgsbqfhdXbsNZE0Aojfqov iheGKAh1s9tSABIM9/7BX5dxfNbC0eCb9Xz/PlRwTwuYMQkYtCsw9l/bA+s9qVvfU4bf tv8T3gZUTjyL5GWpwH51x6ZDcmpIucxjRkADE29YyK3Mm7ItM0wgoA2uXwe+25Qga1Wv ETrEVxenOvYW1A8luxQetGgXzYmzFABDctsUQXl2UdamMbjHontVmqcMxw3bspMT9kMm vpIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=5D8HZvZEe/8lXXC8RDPgDlCIU7jVNZg1VgzYXVGl8+A=; b=RLmkYrFDoq/z9xF8mfkYPv+QQjy1rLl+gCs7/W+/G7BykMJ8vH/qwPmK71GOD5pHBD 4yju1BTZ99IA0ZsUxXn76MiGkiqIHin5FpRujxk1UGruJ0a/MWoKPsT8uFF0SQJE1Dap MRdjBBh0llK8yGoVxzdrFGsqJAO/KBIzT7E0zcVsjTXpQQP5Rku1HDlB0/TGM8wn4cuq kcsOI4ZQmpSNCX9KuKxgFL7XVpcWvylxMyafwvyUQHOzmCZjLHJSOX3oftAC06wkbgdN dt7VkczqfoLYHgTBZQ4VIvhGMUsZ/PVMQGB1ayg6IC7K0C+Cjkoz+sHJ1DE/cPu9///m 6L3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i3si3691301edl.184.2020.05.18.08.26.19; Mon, 18 May 2020 08:26:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728297AbgERPW7 convert rfc822-to-8bit (ORCPT + 99 others); Mon, 18 May 2020 11:22:59 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:40489 "EHLO relay9-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726918AbgERPW7 (ORCPT ); Mon, 18 May 2020 11:22:59 -0400 X-Originating-IP: 91.224.148.103 Received: from xps13 (unknown [91.224.148.103]) (Authenticated sender: miquel.raynal@bootlin.com) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 2AAEDFF809; Mon, 18 May 2020 15:22:55 +0000 (UTC) Date: Mon, 18 May 2020 17:22:53 +0200 From: Miquel Raynal To: Bean Huo Cc: richard@nod.at, vigneshr@ti.com, s.hauer@pengutronix.de, boris.brezillon@collabora.com, derosier@gmail.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Bean Huo Subject: Re: [PATCH v4 0/5] Micron SLC NAND filling block Message-ID: <20200518172253.1c3b9d32@xps13> In-Reply-To: <20200518135943.11749-1-huobean@gmail.com> References: <20200518135943.11749-1-huobean@gmail.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bean, Bean Huo wrote on Mon, 18 May 2020 15:59:38 +0200: > From: Bean Huo > > Hi, > > on some legacy planar 2D Micron NAND devices when a block erase command is > issued, occasionally even though a block erase operation completes and returns > a pass status, the flash block may not be completely erased. Subsequent > operations to this block on very rare cases can result in subtle failures or > corruption. These extremely rare cases should nevertheless be considered. This > patchset is to address this potential issue. > > After submission of patch V1 [1] and V2 [2], we stopped its update since we get > stuck in the solution on how to avoid the power-loss issue in case power-cut > hits the block filling. In the v1 and v2, to avoid this issue, we always damaged > page0, page1, this's based on the hypothesis that NAND FS is UBIFS. This > FS-specifical code is unacceptable in the MTD layer. Also, it cannot cover all > NAND based file system. Based on the current discussion, seems that re-write all > first 15 page from page0 is a satisfactory solution. We have a layering problem now. Maybe we should just have an MTD internal variable like min_written_pages_before_erase that the Micron driver could set to a !0 value. Then, the handling could be done by the user (UBI/UBIFS, JFFS2, MTD user if exported). > > Meanwhile, I borrowed one idea from Miquel Raynal patchset [3], in which keeps > a recode of programmed pages, base on it, for most of the cases, we don't need > to read every page to see if current erasing block is a partially programmed > block. > > Changelog: > > v3 - v4: > 1. In the patch 4/5, change to directly use ecc.strength to judge the page > is a empty page or not, rather than max_bitflips < mtd->bitflip_threshold > 2. In the patch 5/5, for the powerloss case, from the next time boot up, > lots of page will be programmed from >page15 address, if still using > first_p as GENMASK() bitmask starting position, writtenp will be always 0, > fix it by changing its bitmask starting at bit position 0. > > v2 - v3: > 1. Rebase patch to the latest MTD git tree > 2. Add a record that keeps tracking the programmed pages in the first 16 > pages > 3. Change from program odd pages, damage page 0 and page 1, to program all > first 15 pages > 4. Address issues which exist in the V2. > > v1 - v2: > 1. Rebased V1 to latest Linux kernel. > 2. Add erase preparation function pointer in nand_manufacturer_ops. > > > [1] https://www.spinics.net/lists/linux-mtd/msg04112.html > [2] https://www.spinics.net/lists/linux-mtd/msg04450.html > [3] https://www.spinics.net/lists/linux-mtd/msg13083.html > > > Bean Huo (5): > mtd: rawnand: group all NAND specific ops into new nand_chip_ops > mtd: rawnand: Add {pre,post}_erase hooks in nand_chip_ops > mtd: rawnand: Add write_oob hook in nand_chip_ops > mtd: rawnand: Introduce a new function nand_check_is_erased_page() > mtd: rawnand: micron: Micron SLC NAND filling block When you take my patches in your series, especially when not touching them at all, you should keep my Authorship and SoB first, then add your SoB. Thanks, Miquèl