Received: by 10.192.165.156 with SMTP id m28csp1613208imm; Wed, 11 Apr 2018 23:54:07 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/YE1l0vNFeYIeHzUBotvXZP8WlPG2qvrHVyr1XvKlg8uIXstpSSNE0LIXXxzxQkZwG/Edm X-Received: by 2002:a17:902:722:: with SMTP id 31-v6mr8332914pli.38.1523516046962; Wed, 11 Apr 2018 23:54:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523516046; cv=none; d=google.com; s=arc-20160816; b=VkUBBiAxazeznVPQG3RpPrGUqfaOk/eTcvXU7fTxhxCE4OOgAnafueyVa5VghiieuE 5K56SRYxoTC3wFY1/gSIFyK/tzgx+1xzQhOxWYz/5b06hF9BFDYJe+Xu0wSfm6HHN0iJ ya+OqAkkJAIz6gZie2GfjgFVR9O+NvjS+mhzIB8Rd4fDGVYE1p9NoRY5YVKl/l9KT4WX dl15HW3ASsKvWaDHQa1qFfPC+WiQYkT8mmQpCdbv28H6lDmVrAEwNc00vKsEKqnSXYv1 +5zkJd10oCWwu7MM58iMOVnfweO8ZxRnSmkBaXKMfF797W1LVTpnXFlktMPSXQ3NSx0V elzA== 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=Hb87Vgsx7GkNNMT83iwp+siF3xaMQ3pBX3O13OQ+Ol8=; b=HJ9GY0XXFAdPJ7AharOrGr8hLqV3oF4HNFqcuu+sScj4JhSNGDbr6hooh3A/2GIK5Q YjLtrZ3/UkLEQuwAWHME93E/LkmARo0Mj4P/ZF4K/BPlr6wQqXwMY0XO8ameJPn7BJd9 T6OSg+wafm+jiQDYmUYkj5o71n/r4m8tuTfLYLd1KMgXzHy6EPUiQ1yX57+IbTRwdZ48 hwa/0c19n0pOsr23PmOovmG1aDWS/TXeVdnHormB8bUCkdIg3w2CywzLrqhDQTTwk4DL U8UatJ6avSjlbaAO3M/lOzArVk0eMIpQ0z1KhWsE+CjHuBUKf2U1QWzrz5ogpBXBkTI8 5v2w== 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 bf10-v6si2810829plb.417.2018.04.11.23.53.29; Wed, 11 Apr 2018 23:54:06 -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 S1752846AbeDLGuO convert rfc822-to-8bit (ORCPT + 99 others); Thu, 12 Apr 2018 02:50:14 -0400 Received: from mail.bootlin.com ([62.4.15.54]:43777 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752401AbeDLGuM (ORCPT ); Thu, 12 Apr 2018 02:50:12 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id D7DE52084F; Thu, 12 Apr 2018 08:50:10 +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 44F8D20712; Thu, 12 Apr 2018 08:49:29 +0200 (CEST) Date: Thu, 12 Apr 2018 08:49:19 +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 3/9] mtd: nand: qcom: erased page detection for uncorrectable errors only Message-ID: <20180412084919.1ca7991d@xps13> In-Reply-To: <2c93157a2982365ceaa8af17d5e3b97a@codeaurora.org> 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> 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 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. > > >> >> 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? Thanks, Miquèl > if (ret < 0) { > mtd->ecc_stats.failed++; > } else { > mtd->ecc_stats.corrected += ret; > > Already, it is incrementing mtd->ecc_stats.failed > > Thanks, > Abhishek -- Miquel Raynal, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com