Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1996504imm; Sun, 27 May 2018 22:46:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqRvs0KZglMH8j2LkHFCKuChmyzBHE2xd6CCi+ai2fP2CbMclWYm2APtnq9J7XohkLgK6B9 X-Received: by 2002:a62:8ac1:: with SMTP id o62-v6mr12214766pfk.141.1527486419045; Sun, 27 May 2018 22:46:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527486419; cv=none; d=google.com; s=arc-20160816; b=a6V82dMpevc+cK15oxP783/t0thu8Jw9SA+BOE2ZxClfN2NvBzjIvlXXVs3Dq6SD51 gbjUsoX+t9cAAu5thte+5hCcX5nmNww+udFkTCx7IeQdk2mLGmpGd9rwQqqbv350jdAD i9djgZRAtDalrFNE0eb6FIHmLwVheUWeWhPuk1IzS4WW+84u0tnbezRoThLbc0feaywe LROtpem4Gtqk2wPjyTUt6iUuqHqhgldbv3Sff6G+eMV7KXuz0w8pfZoMc+3iMCjjDZnW g2e8CQHwziyIcf9VTWkfEAwnVNTrrb7ShZ3vJa+wRssTidk9w6RM1WHma7aiIT5ECysz UwPA== 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=2TqwOdlbSk1n7CvWLoJppiRYV5x/7cDiB9nRJZP0iV0=; b=g1wLd8/+zYivsZwi8TqgXFse/1XLsJOvzj85jTGgaDwTVR2B8PvcGLxK7Ye4qfVEmj l4nJ7cdElK4sv5/H7p8PNwjgebDe0Qn+L/mebPrOxQi8Ntzgoygq4XU90F0IgAj2HsXe Vo3kyfN/bDovVPXiLI5I36dwyn7SSovNuG8cBVJqdXubvgm1gwni8erAN/2Nmt5b0bZ+ iHMzHMnjbkdj0LdXIFtN9JYfyaGZVwR+jZS+P2IJKxNpFlngCjrw6evTZ8UlJFpFydBi yNQ4Bx08QCKEtT0OvZmC+S9AvIQf5QmLS44J2OLMMP/kT8xaAHYuJJkB/INQovW4D3v1 UpIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=k8VoFFNm; dkim=pass header.i=@codeaurora.org header.s=default header.b=j6GkHy5e; 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 g1-v6si13997571pgu.97.2018.05.27.22.46.43; Sun, 27 May 2018 22:46:59 -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=k8VoFFNm; dkim=pass header.i=@codeaurora.org header.s=default header.b=j6GkHy5e; 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 S1753261AbeE1Fqd (ORCPT + 99 others); Mon, 28 May 2018 01:46:33 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:54046 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751838AbeE1Fqb (ORCPT ); Mon, 28 May 2018 01:46:31 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id F189D60C4F; Mon, 28 May 2018 05:46:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527486391; bh=QUJ4EY3cQYkgTxBP4MafKe/iZ+Icfx456gNp1XU96Dg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=k8VoFFNm1Y9DuNPqmvTIIcBUyYk0zv3xjVE4KKpexCLhMszay1jkECSv4X6X+kBaQ rbAB8BZUdbnnMEMO1apLUXtXPQ0KmHZNi30oJQb0GabuoNPANWLN0U+RRh8bi4Cv7Y Z9K8NXXq5wIjmYwrQW80sw+kK4oCg9xgV6pHRnt8= 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 8270F6025C; Mon, 28 May 2018 05:46:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527486389; bh=QUJ4EY3cQYkgTxBP4MafKe/iZ+Icfx456gNp1XU96Dg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=j6GkHy5eenUYgmGyqlN4UsefaIc2+Ak3KYGr3r/mZThb5ZMt9sPeKjElbfQw/hZtA 4x1V2z8dAMfFF/x8Mch+Gu4rLx7KjBZ76lxb/hnH9cxtyAn+6nDmtUk1ZKovkOUDPO JKUDjdnELT/PLayVuvGoE2eKFbwDa/E2Fsv8okr4= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 28 May 2018 11:16:29 +0530 From: Abhishek Sahu To: Miquel Raynal Cc: Boris Brezillon , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Cyrille Pitchen , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Andy Gross , Archit Taneja , Masahiro Yamada Subject: Re: [PATCH v3 01/16] mtd: rawnand: helper function for setting up ECC configuration In-Reply-To: <20180526095807.5caf5800@xps13> References: <1527250904-21988-1-git-send-email-absahu@codeaurora.org> <1527250904-21988-2-git-send-email-absahu@codeaurora.org> <20180526095807.5caf5800@xps13> Message-ID: <44d4939cf8411a0dc693b8dd11fb57c7@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-05-26 14:12, Miquel Raynal wrote: > Hi Abhishek, > > On Fri, 25 May 2018 17:51:29 +0530, Abhishek Sahu > wrote: > >> 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. >> >> This patch introduces nand_ecc_choose_conf 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 v2: >> >> 1. Renamed function to nand_ecc_choose_conf. >> 2. Minor code reorganization to remove warning and 2 function calls >> for nand_maximize_ecc. >> >> * Changes from v1: >> NEW PATCH >> >> drivers/mtd/nand/raw/nand_base.c | 42 >> ++++++++++++++++++++++++++++++++++++++++ >> drivers/mtd/nand/raw/nand_base.c | 31 +++++++++++++++++++++++++++++++ >> include/linux/mtd/rawnand.h | 3 +++ >> 2 files changed, 34 insertions(+) >> >> diff --git a/drivers/mtd/nand/raw/nand_base.c >> b/drivers/mtd/nand/raw/nand_base.c >> index 72f3a89..e52019d 100644 >> --- a/drivers/mtd/nand/raw/nand_base.c >> +++ b/drivers/mtd/nand/raw/nand_base.c >> @@ -6249,6 +6249,37 @@ int nand_maximize_ecc(struct nand_chip *chip, >> } >> EXPORT_SYMBOL_GPL(nand_maximize_ecc); >> >> +/** >> + * nand_ecc_choose_conf - 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 configuration 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. >> + * >> + * On success, the chosen ECC settings are set. >> + */ >> +int nand_ecc_choose_conf(struct nand_chip *chip, >> + const struct nand_ecc_caps *caps, int oobavail) >> +{ >> + if (chip->ecc.size && chip->ecc.strength) >> + return nand_check_ecc_caps(chip, caps, oobavail); >> + >> + if (!(chip->ecc.options & NAND_ECC_MAXIMIZE) && >> + !nand_match_ecc_req(chip, caps, oobavail)) >> + return 0; >> + >> + return nand_maximize_ecc(chip, caps, oobavail); > > I personally don't mind if nand_maximize_ecc() is called twice in > the function if it clarifies the logic. Maybe the following will be > more clear for the user? Thanks Miquel. Both the implementations are fine. The above implementation (which was in Denali NAND driver) code was also clear. We can go for any of these implementation. Shall I update this ? > > 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; > > return nand_maximize_ecc(chip, caps, oobavail); > > Also, I'm not sure we should just error out when nand_check_ecc_caps() > fails. What about something more robust, like: > But again, It will lead in overriding the DT ECC strength parameter. We started our discussion from that point. :-) Thanks, Abhishek > int ret; > > if (chip->ecc.size && chip->ecc.strength) { > ret = nand_check_ecc_caps(chip, caps, oobavail); > if (ret) > goto maximize_ecc; > > return 0; > } > > if (chip->ecc.options & NAND_ECC_MAXIMIZE) > goto maximize_ecc; > > ret = nand_match_ecc_req(chip, caps, oobavail); > if (ret) > goto maximize_ecc; > > return 0; > > maximize_ecc: > return nand_maximize_ecc(chip, caps, oobavail); > >> +} >> +EXPORT_SYMBOL_GPL(nand_ecc_choose_conf); >> + >> /* >> * Check if the chip configuration meet the datasheet requirements. >> >> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h >> index 5dad59b..89889fa 100644 >> --- a/include/linux/mtd/rawnand.h >> +++ b/include/linux/mtd/rawnand.h >> @@ -1627,6 +1627,9 @@ int nand_match_ecc_req(struct nand_chip *chip, >> int nand_maximize_ecc(struct nand_chip *chip, >> const struct nand_ecc_caps *caps, int oobavail); >> >> +int nand_ecc_choose_conf(struct nand_chip *chip, >> + const struct nand_ecc_caps *caps, int oobavail); >> + >> /* Default write_oob implementation */ >> int nand_write_oob_std(struct mtd_info *mtd, struct nand_chip *chip, >> int page); >> > > Thanks, > Miquèl