Received: by 10.192.165.148 with SMTP id m20csp2714407imm; Sun, 6 May 2018 23:03:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqzRTwCjZeS891E3c2xbA1MJAFVibgF0lPizyttJH0AEvqeGr5qZ8pwBxMzPOc8o1CJHF6N X-Received: by 10.98.30.2 with SMTP id e2mr23264792pfe.212.1525673013001; Sun, 06 May 2018 23:03:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525673012; cv=none; d=google.com; s=arc-20160816; b=ARuPYPBc2WCYLYLDPLwTdByBsghTcsn0SqG2IU5wajPSQ1j4eyYfcw+sHxzFgeMh/V s4melm06/w85aXBwyCCJVMKvzxOOy+54laooZLKeuqWwKXkgLiFgXSsYFEVbjT4FthOa 57PUcMUvS3EmClGzit+hw1lRCbfe1PFZu9NOC8rXobvsFDWJweLAyjhRBct7BU6zz9t+ qqSIC7EM4isrmrM8JsmDZYiF7oz1DX2A0+iDKN3TC5Ps2kDRCHb+y6J5223OBymNV7k7 UdDdPWy6wEKiCDyAbva/DC9L6yYYOQXLLBlkwE1QoRw3pGnHsrf8jxBsfat/yLJQhUvn vg5g== 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=LSUr4Vc99pVXCwjEh7+OHsXtmPdmgiNkoMgxfJIqLbk=; b=ttRtk2L13IZjNoyURE6/6LRAlD4IwuH09L4C+heCE4vtG81VmdeKPBwF7SFxIQOBH0 20YOW8KsO6YSWUjce734/Y5h9k8G5SInOyv9gFuPtcOZA0vDAOeOZVCQ66JgNM8hu7yE /E+T9IIP2Z/Wh+GDc2/ISXk2z9hrKCSQzwmSFxOJP31qpBRdjRN6iDHkHlqitwUf1i7O XdA1Askvrwe+VQk4ZeYaiH3TAc8XpPNaFjPNw4iyzPvdfcoPYypSNXSlOzJ8pwpsDedI B4qduQ4aTIZI/Po4z4bTiHFnU8Ck6gNmNmQCHxAmQjVqYp79eXGLChzpYldrAvq6cpTO a0SQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=DR7Jwcc5; dkim=pass header.i=@codeaurora.org header.s=default header.b=ErlBD6OZ; 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 2si5531821pfk.287.2018.05.06.23.03.18; Sun, 06 May 2018 23:03:32 -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=DR7Jwcc5; dkim=pass header.i=@codeaurora.org header.s=default header.b=ErlBD6OZ; 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 S1750980AbeEGGCC (ORCPT + 99 others); Mon, 7 May 2018 02:02:02 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:47332 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750708AbeEGGCA (ORCPT ); Mon, 7 May 2018 02:02:00 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 21C5060A06; Mon, 7 May 2018 06:01:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1525672920; bh=DMl0eRRQ/DMfcDAuFqhjYhL3eV5q4PHLTg+pEBs9tLc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DR7Jwcc5KmghzSdkLeIze+PTOVUGVHdTa1qe/3QqR/bK1G+4UYQk/LXACBlTHGZnC nPUdQ0Qjth1aCHdiDT47MNgrC9vx2IrEMeiUK/u6MwS8glNi+sQ8em4ESrYRJ83M0Y Af0wud34ftjhPf/VrSziKpqK3lz9nc5XgssdXkuU= 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 750EC60115; Mon, 7 May 2018 06:01:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1525672918; bh=DMl0eRRQ/DMfcDAuFqhjYhL3eV5q4PHLTg+pEBs9tLc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ErlBD6OZbHqdMEN3S6Yw5eUgQEpLKQy0yRRywV1v5iQCuKEZRaHDhNGfFJaLPtxtM vOQg4ZcvVwd8JZsmtbJYbfye1ksQbfYyMDtM7FXr54CqoMdpK5XRuZXGtAhsLhhiwV laUeVQzt+I4LF2D6FMMgHNui9hfEiyWBHaNAnUSI= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 07 May 2018 11:31:58 +0530 From: Abhishek Sahu To: Masahiro Yamada Cc: Boris Brezillon , Archit Taneja , Richard Weinberger , linux-arm-msm , Linux Kernel Mailing List , Marek Vasut , linux-mtd , Miquel Raynal , Andy Gross , Brian Norris , David Woodhouse Subject: Re: [PATCH v2 01/14] mtd: rawnand: helper function for setting up ECC parameters In-Reply-To: References: <1525350041-22995-1-git-send-email-absahu@codeaurora.org> <1525350041-22995-2-git-send-email-absahu@codeaurora.org> Message-ID: 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-05-07 09:10, Masahiro Yamada wrote: > 2018-05-03 21:20 GMT+09:00 Abhishek Sahu : >> commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check, >> match, maximize ECC settings") provides generic helpers which >> drivers can use for setting up ECC parameters. >> >> Since same board can have different ECC strength nand chips so >> following is the logic for setting up ECC strength and ECC step >> size, which can be used by most of the drivers. >> >> 1. If both ECC step size and ECC strength are already set >> (usually by DT) then just check whether this setting >> is supported by NAND controller. >> 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength >> supported by NAND controller. >> 3. Otherwise, try to match the ECC step size and ECC strength closest >> to the chip's requirement. If available OOB size can't fit the chip >> requirement then select maximum ECC strength which can be fit with >> available OOB size with warning. >> >> This patch introduces nand_ecc_param_setup function which calls the >> required helper functions for the above logic. The drivers can use >> this single function instead of calling the 3 helper functions >> individually. >> >> CC: Masahiro Yamada >> Signed-off-by: Abhishek Sahu >> --- >> * Changes from v1: >> >> NEW PATCH >> >> drivers/mtd/nand/raw/nand_base.c | 42 >> ++++++++++++++++++++++++++++++++++++++++ >> include/linux/mtd/rawnand.h | 3 +++ >> 2 files changed, 45 insertions(+) >> >> diff --git a/drivers/mtd/nand/raw/nand_base.c >> b/drivers/mtd/nand/raw/nand_base.c >> index 72f3a89..dd7a984 100644 >> --- a/drivers/mtd/nand/raw/nand_base.c >> +++ b/drivers/mtd/nand/raw/nand_base.c >> @@ -6249,6 +6249,48 @@ int nand_maximize_ecc(struct nand_chip *chip, >> } >> EXPORT_SYMBOL_GPL(nand_maximize_ecc); >> >> +/** >> + * nand_ecc_param_setup - Set the ECC strength and ECC step size >> + * @chip: nand chip info structure >> + * @caps: ECC engine caps info structure >> + * @oobavail: OOB size that the ECC engine can use >> + * >> + * Choose the ECC strength according to following logic >> + * >> + * 1. If both ECC step size and ECC strength are already set (usually >> by DT) >> + * then check if it is supported by this controller. >> + * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength. >> + * 3. Otherwise, try to match the ECC step size and ECC strength >> closest >> + * to the chip's requirement. If available OOB size can't fit the >> chip >> + * requirement then fallback to the maximum ECC step size and ECC >> strength >> + * and print the warning. >> + * >> + * On success, the chosen ECC settings are set. >> + */ >> +int nand_ecc_param_setup(struct nand_chip *chip, >> + const struct nand_ecc_caps *caps, int >> oobavail) >> +{ >> + int ret; >> + >> + if (chip->ecc.size && chip->ecc.strength) >> + return nand_check_ecc_caps(chip, caps, oobavail); >> + >> + if (chip->ecc.options & NAND_ECC_MAXIMIZE) >> + return nand_maximize_ecc(chip, caps, oobavail); >> + >> + if (!nand_match_ecc_req(chip, caps, oobavail)) >> + return 0; >> + >> + ret = nand_maximize_ecc(chip, caps, oobavail); > > > Why two calls for nand_maximize_ecc()? > > My code is simpler, and does not display > false-positive warning. > Thanks Masahiro. Since, Now this is in moved to generic layer that's why I put this warning that this function is falling back to some other ECC settings which is not recommend by chip. If this warning seems unnecessary then I can remove this and then directly your code changes can be put here instead of calling nand_maximize_ecc 2 times. > >> + if (!ret) >> + pr_warn("ECC (step, strength) = (%d, %d) not supported >> on this controller. Fallback to (%d, %d)\n", >> + chip->ecc_step_ds, chip->ecc_strength_ds, >> + chip->ecc.size, chip->ecc.strength); > > > This is annoying. > > {ecc_step_ds, ecc_strength_ds} are not provided by Non-ONFi devices. > > So, > ECC (step, strength) = (0, 0) not supported on this controller. > > will be always displayed. > > > The strength will be checked by nand_ecc_strength_good() anyway. > But for most of the non ONFI devices also, this is being calculated by ID. You can get some background for this in http://lists.infradead.org/pipermail/linux-mtd/2018-April/080193.html Regards, Abhishek