Received: by 10.192.165.156 with SMTP id m28csp1618895imm; Thu, 12 Apr 2018 00:01:49 -0700 (PDT) X-Google-Smtp-Source: AIpwx48URo5ICueKvcLRlI0SBW6QP3xuK7JMZKraWPCu4+eiFhMGF5D/D++cohHK8Iywj2rWvZ4x X-Received: by 10.98.223.149 with SMTP id d21mr6627191pfl.160.1523516509517; Thu, 12 Apr 2018 00:01:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523516509; cv=none; d=google.com; s=arc-20160816; b=ZnmrMXdZgILBdZOnpr/QaoCzPKU6Orb6NAQBg5B+g26fmoL0qWEJSNW/2LnGQIXsMp 6NhHdjbtMXXArH/I/pHf1oILB0mCGUWDcjq5cYlbaTxAEZDi9d7BYUK7wKakKWm0J+Q0 a/A8O4sN0TUlBgjZ1qtBsCTp/Tkzmi0oxB42K6ZhL1fBQlRWYw2G9+06KKBuxCUN823a h//a3ZzPFYK1UmdjsNbCaiLhi0MlEybAxqmRa6lmX229GxLp5E8AOzELFN5dJLhJnVMZ gs4Yx+2CVqd68Jyd0pFxfvQK56yAG1AvMxfUBM9JS3b2fJs2nW9he/yYV7o2who2bIPe SAjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=hEGgaGQlV4KcDeV6eSVD4RtsxBo+NMuZcD2AGy5awKc=; b=XtYNvw4GRwTZS5BmdyAtNivzHm4dYdqv+5fygI7DGCxiYn/16GArO3nyri7EN6vaes jtzE3tBgJByqJIJ7WVOGi+tpmx6IF+Gd0oCRkNm8se4Gi73Mf8Lkos8xoo4oQVmqMFZh nd3yf6tcBzWXde74aM6hbk3OBQhdIAum8vBgcjvYM+WsOZnMs6Ebh2UdkAQT4MhDxLKS nmYnRaLCgiCU3u1B9Pz4k0mE4dEjyEi/aEPXw19553X6qI+wwLFUmKY7bPb3EgaXWp4l VK6gX2QjXdMbHsfmwt/XMaYdwPjJJAv5yGP8R7w59xhMIRBMjEKIrvy9l/lCcCG9WsGd Lwmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=QTmEDTMV; dkim=pass header.i=@codeaurora.org header.s=default header.b=IIfR4ZN4; 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 z85si2148604pfk.194.2018.04.12.00.01.12; Thu, 12 Apr 2018 00:01:49 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=QTmEDTMV; dkim=pass header.i=@codeaurora.org header.s=default header.b=IIfR4ZN4; 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 S1752829AbeDLG6J (ORCPT + 99 others); Thu, 12 Apr 2018 02:58:09 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:39248 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752396AbeDLG6H (ORCPT ); Thu, 12 Apr 2018 02:58:07 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 9E6B460807; Thu, 12 Apr 2018 06:58:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523516286; bh=5FDPsxYEiGsMai1aRb/47uicA9Mj6Cdr+V1ioa2Pk1M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QTmEDTMVXkpVY0TXAvl8/w4F0tBa9zaGhe39WwMhlv/vFW4qULpcMjG9v0KIE/Spm WCNhIau+ax0HqLVTF9O9PAGEkk6ClmQz1bkFLatrJuHfwHLofQVKRZ+g+WbtzOmqeM IbEBdCv52G/S4Ibd8LnBfrp/geQB3BzxY9Qi7pO0= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 9AD2160540; Thu, 12 Apr 2018 06:58:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523516285; bh=5FDPsxYEiGsMai1aRb/47uicA9Mj6Cdr+V1ioa2Pk1M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IIfR4ZN4vKMKjix0cqIuujofFye/PLzJFOfXVkRVIapHz2e0uM4GaXRn5SSRp+Aii 9RmhKN4gsRJuErzHsTpHHCA+RGGyJ2wayYZAJcFdqHLFbjfuRiNdIHiL3PLRpgK2nx 1B6hjlM7QEvQHcJHKL4Y814NYwrud+DajdNVzl4s= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 12 Apr 2018 12:28:05 +0530 From: Abhishek Sahu To: Miquel Raynal 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 , linux-arm-msm-owner@vger.kernel.org Subject: Re: [PATCH 3/9] mtd: nand: qcom: erased page detection for uncorrectable errors only In-Reply-To: <20180412084919.1ca7991d@xps13> References: <1522845745-6624-1-git-send-email-absahu@codeaurora.org> <1522845745-6624-4-git-send-email-absahu@codeaurora.org> <20180410105945.65f2cade@xps13> <2c93157a2982365ceaa8af17d5e3b97a@codeaurora.org> <20180412084919.1ca7991d@xps13> Message-ID: <67cfecb5ca845fac636fb5129150950a@codeaurora.org> X-Sender: absahu@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-04-12 12:19, Miquel Raynal wrote: > Hi Abhishek, > > On Thu, 12 Apr 2018 12:03:58 +0530, Abhishek Sahu > wrote: > >> On 2018-04-10 14:29, Miquel Raynal wrote: >> > Hi Abhishek, >> > > On Wed, 4 Apr 2018 18:12:19 +0530, Abhishek Sahu >> > wrote: >> > >> The NAND flash controller generates ECC uncorrectable error >> >> first in case of completely erased page. Currently driver >> >> applies the erased page detection logic for other operation >> >> errors also so fix this and return EIO for other operational >> >> errors. >> > > I am sorry I don't understand very well what is the purpose of this >> > patch, could you please explain it again? >> > > Do you mean that you want to avoid having rising ECC errors when you >> > read erased pages? >> > Thanks Miquel for your review. >> >> QCOM NAND flash controller has in built erased page >> detection HW. >> Following is the flow in the HW if controller tries >> to read erased page >> >> 1. First ECC uncorrectable error will be generated from >> ECC engine since ECC engine first calculates the ECC with >> all 0xff and match the calculated ECC with ECC code in OOB >> (which is again all 0xff). >> 2. After getting ECC error, erased CW detection HW checks if >> all the bytes in page are 0xff and then it updates the >> status in separate register NAND_ERASED_CW_DETECT_STATUS >> >> So the erased CW detect status should be checked only if >> ECC engine generated the uncorrectable error. >> >> Currently for all other operational errors also (like TIMEOUT, >> MPU errors etc), the erased CW detect register was being >> checked. > > This is very clear, thanks. I don't know very much this controller so I > think you can add this information in the commit message for future > reference. > Sure Miquel. I Will update the commit message to include more detail. >> >> >> >> Signed-off-by: Abhishek Sahu >> >> --- >> >> drivers/mtd/nand/qcom_nandc.c | 8 +++++++- >> >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> >> diff --git a/drivers/mtd/nand/qcom_nandc.c >> b/drivers/mtd/nand/qcom_nandc.c >> >> index 17321fc..57c16a6 100644 >> >> --- a/drivers/mtd/nand/qcom_nandc.c >> >> +++ b/drivers/mtd/nand/qcom_nandc.c >> >> @@ -1578,6 +1578,7 @@ static int parse_read_errors(struct >> qcom_nand_host *host, u8 *data_buf, >> >> struct nand_ecc_ctrl *ecc = &chip->ecc; >> >> unsigned int max_bitflips = 0; >> >> struct read_stats *buf; >> >> + bool flash_op_err = false; >> >> int i; >> >> >> buf = (struct read_stats *)nandc->reg_read_buf; >> >> @@ -1599,7 +1600,7 @@ static int parse_read_errors(struct >> qcom_nand_host *host, u8 *data_buf, >> >> buffer = le32_to_cpu(buf->buffer); >> >> erased_cw = le32_to_cpu(buf->erased_cw); >> >> >> - if (flash & (FS_OP_ERR | FS_MPU_ERR)) { >> >> + if ((flash & FS_OP_ERR) && (buffer & BS_UNCORRECTABLE_BIT)) { >> > > And later you have another "if (buffer & BS_UNCORRECTABLE_BIT)" which >> > is then redundant, unless that is not what you actually want to do? >> >> Yes. That check seems to be redundant. I will fix that. >> >> > > Maybe you can add comments before the if ()/ else if () to explain in >> > which case you enter each branch. >> >> Sure. That would be better. Will add the same in next patch set. >> >> > >> bool erased; >> >> >> /* ignore erased codeword errors */ >> >> @@ -1641,6 +1642,8 @@ static int parse_read_errors(struct >> qcom_nand_host *host, u8 *data_buf, >> >> max_t(unsigned int, max_bitflips, ret); >> >> } >> >> } >> >> + } else if (flash & (FS_OP_ERR | FS_MPU_ERR)) { >> >> + flash_op_err = true; >> >> } else { >> >> unsigned int stat; >> >> >> @@ -1654,6 +1657,9 @@ static int parse_read_errors(struct >> qcom_nand_host *host, u8 *data_buf, >> >> oob_buf += oob_len + ecc->bytes; >> >> } >> >> >> + if (flash_op_err) >> >> + return -EIO; >> >> + >> > > In you are propagating an error related to the controller, this is >> > fine, but I think you just want to raise the fact that a NAND >> > uncorrectable error occurred, in this case you should just increment >> > mtd->ecc_stats.failed and return 0 (returning max_bitflips here would > be >> > fine too has it would be 0 too). >> >> The flash_op_err will be for other operational errors only (like >> timeout, >> MPU error, device failure etc). For correctable errors, >> >> ret = nand_check_erased_ecc_chunk(data_buf, >> data_len, eccbuf, ecclen, oob_buf, >> extraooblen, ecc->strength); > > Why do you need nand_check_erased_ecc_chunk() if the blank page check > is done in hw? > This is only applicable for BCH algorithm. IPQ806x uses RS code for 4 bit ECC which does not have HW blank page detection. You can get more detail in function comment of erased_chunk_check_and_fixup /* * when using BCH ECC, the HW flags an error in NAND_FLASH_STATUS if it read * an erased CW, and reports an erased CW in NAND_ERASED_CW_DETECT_STATUS. * * when using RS ECC, the HW reports the same erros when reading an erased CW, * but it notifies that it is an erased CW by placing special characters at * certain offsets in the buffer. * * verify if the page is erased or not, and fix up the page for RS ECC by * replacing the special characters with 0xff. */ static bool erased_chunk_check_and_fixup(u8 *data_buf, int data_len) { Thanks, Abhishek