Received: by 10.213.65.68 with SMTP id h4csp3711084imn; Tue, 10 Apr 2018 03:33:37 -0700 (PDT) X-Google-Smtp-Source: AIpwx48mreu/oBEwWttSx0Q8CNccJ4WJpKsqh38AwFzmsBuUkyf17m/5nb52k1jWqy0U0fE5ydVz X-Received: by 10.98.9.134 with SMTP id 6mr2244545pfj.207.1523356417055; Tue, 10 Apr 2018 03:33:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523356417; cv=none; d=google.com; s=arc-20160816; b=PGdOCqmLo2inaELPK5Lx+OXUpXeEVwMVngNHWYs89UrXFsEcIrCZWyZDz+V7vErFe+ Kgwr5VZ44iYE5R7IYNi1EVxJ7SCzd8GbHCrKjKrRd8M03blFEXF+lC3XvNTCmkj85uyF PlPbqjVnc5ljjLJjUSplzurMmImi5iAVQCih/x+q4VcATcGxK6tYBh7OobwsFUcl4X96 69ElmT1rbaeRSouiMld0c96lvb42RPNsIS2dblE+fkymYvHXfTN5UTX5RUcAmXptvbCE KJ4aNgHtbCiFT1XYcbZUAa+dqHehBF7W0v70Q+tmExscFTBkTzGjGxtIdyYS0XAlu+PB 0djw== 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:arc-authentication-results; bh=X6ALDMUj+2j/rt5B1cb4vNXmAfG/cpHRDCt7z2ybMrc=; b=Hnd5tsYnM78FuRJXB4SiavhN4tHLcCjSimQOcoM1j2ujI5EUQtETRtWdHhWpKJN+Ce O/MS996BORu4kUeV1gMcyOSoVyhtmC/BuJ7873Ke5yxNhQxcDfmzHFLDSWMacQscoos/ ybyf55NkT3fRNjPzHd9ai22N0FVXanX1pSgiedpBykfcLbS702ZxcLrWW/Ho2tOh7utm bQW6Kc7eoFr34/64Mx7d5cJ0c0QSdrWxwQK1M9aj+Gkve+V9hCj95rTy+JeMrOxrfgQM 8VesaUwJrGGXkDBOrXYrUxplEiTCCvBUNPiaDGZhDhD4j+eq2WvQVjEKs0BN/IloeqLP cf2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t6-v6si2370396plr.661.2018.04.10.03.33.00; Tue, 10 Apr 2018 03:33:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752603AbeDJKaH convert rfc822-to-8bit (ORCPT + 99 others); Tue, 10 Apr 2018 06:30:07 -0400 Received: from mail.bootlin.com ([62.4.15.54]:43693 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752424AbeDJKaG (ORCPT ); Tue, 10 Apr 2018 06:30:06 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 1239E20712; Tue, 10 Apr 2018 12:30:04 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from xps13 (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id AB57F20384; Tue, 10 Apr 2018 12:30:03 +0200 (CEST) Date: Tue, 10 Apr 2018 12:30:03 +0200 From: Miquel Raynal To: Abhishek Sahu Cc: Boris Brezillon , Archit Taneja , Richard Weinberger , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Marek Vasut , linux-mtd@lists.infradead.org, Cyrille Pitchen , Andy Gross , Brian Norris , David Woodhouse Subject: Re: [PATCH 9/9] mtd: nand: qcom: erased page bitflips detection Message-ID: <20180410123003.34f4cfaa@xps13> In-Reply-To: <1522845745-6624-10-git-send-email-absahu@codeaurora.org> References: <1522845745-6624-1-git-send-email-absahu@codeaurora.org> <1522845745-6624-10-git-send-email-absahu@codeaurora.org> Organization: Bootlin X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; 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 Abhishek, On Wed, 4 Apr 2018 18:12:25 +0530, Abhishek Sahu wrote: > Some of the newer nand parts can have bit flips in an erased > page due to the process technology used. In this case, qpic AFAIK, this has always been possible, it was just rare. > nand controller is not able to identify that page as an erased > page. Currently the driver calls nand_check_erased_ecc_chunk for > identifying the erased pages but this won’t work always since the > checking is being with ECC engine returned data. In case of > bitflips, the ECC engine tries to correct the data and then it > generates the uncorrectable error. Now, this data is not equal to > original raw data. For erased CW identification, the raw data > should be read again from NAND device and this > nand_check_erased_ecc_chunk function should be called for raw > data only. Absolutely. > > Now following logic is being added to identify the erased > codeword bitflips. > > 1. In most of the case, not all the codewords will have bitflips > and only single CW will have bitflips. So, there is no need to > read the complete raw page data. The NAND raw read can be > scheduled for any CW in page. The NAND controller works on CW > basis and it will update the status register after each CW read. > Maintain the bitmask for the CW which generated the uncorrectable > error. > 2. Schedule the raw flash read from NAND flash device to > NAND controller buffer for all these CWs between first and last > uncorrectable errors CWs. Copy the content from NAND controller > buffer to actual data buffer only for the uncorrectable errors > CWs so that other CW data content won’t be affected, and > unnecessary data copy can be avoided. In case of uncorrectable error, the penalty is huge anyway. > 3. Both DATA and OOB need to be checked for number of 0. The > top-level API can be called with only data buf or oob buf so use > chip->databuf if data buf is null and chip->oob_poi if > oob buf is null for copying the raw bytes temporarily. You can do that. But when you do, you should tell the core you used that buffer and that it cannot rely on what is inside. Please invalidate the page cache with: chip->pagebuf = -1; > 4. For each CW, check the number of 0 in cw_data and usable > oob bytes, The bbm and spare bytes bit flip won’t affect the ECC > so don’t check the number of bitflips in this area. OOB is an area in which you are supposed to find the BBM, the ECC bytes and the spare bytes. Spare bytes == usable OOB bytes. And the BBM should be protected too. I don't get this sentence but I don't see its application neither in the code? > > Signed-off-by: Abhishek Sahu > --- Thanks, Miquèl -- Miquel Raynal, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com