Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3770429imm; Mon, 18 Jun 2018 03:53:34 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIVdZgMqVZUz3qwccD2+heb4juGU6HKNRZowgotJCL3SS+j2xF4rnHBXPgBcof7Ub32vfI/ X-Received: by 2002:a65:53cc:: with SMTP id z12-v6mr10612269pgr.350.1529319214844; Mon, 18 Jun 2018 03:53:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529319214; cv=none; d=google.com; s=arc-20160816; b=ifFTEoDSyW7kHLmhmtx4ApWahLHIgywX8Ob4jiA3BFeYrRRTz/Imt0BCChktGoOHn1 Et91egHf7faiB4okNvGDc3Eog8aUfNAvMXBFzwr7i319Lef3G+hv3iidUn7kYwayoiXS asHy+Nl5UP0pm4s6i/YMxCukTvXldHLiOe4m/RyO4LdjEokZPzRlI0aZjORqGGBthsUl 4LitVcs0RZSCDAnqWp4WyuSbbidupkzCtH2IfgSqSj1D18e3NNb1AGghztJcLabAY7vH YkpnaszHfdL0VNfP3qCoFIMFJ+TEJXvKYtf2xtZrDPoMMX132zTI3zgKlcdNZYMXL0Bp /S7w== 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=WPYGyjXrWULSJjbam0PPkL4aRlLy14tdz0wESkRi0Ow=; b=hhStgWVmd7SUrJ9l3BUvileMzIMF+UudOhXFQLDUciSlFILoz7AtWjy2mP9KiDAUN7 kk2S1/WpIM7H3cO1H7CXQGyXCt4QTh1UUqSe90YC3LkE0F5unI5Ap1TyuXtBzevfXxAk 9saQMxgws+fLEVw1rxze95okyKmVyq2BT+CQDoj818HASRpaTlOCIEGomhCZTa82lrLM J/Xn+3y2q4du+791Qlk8eLt5xooMzl/p/YxC2WkPV6Ve+C1KytYMlxhhOdq20WkomThi JzodgJUGlwYGmeyYmhYXOn5kYVn8H00rH+35MgCRXRjIKaOI2fVhjRo+wprO4RgeiN91 j50w== 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 y35-v6si12120316pga.319.2018.06.18.03.53.21; Mon, 18 Jun 2018 03:53:34 -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 S935268AbeFRKFV convert rfc822-to-8bit (ORCPT + 99 others); Mon, 18 Jun 2018 06:05:21 -0400 Received: from mail.bootlin.com ([62.4.15.54]:57902 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934635AbeFRKFT (ORCPT ); Mon, 18 Jun 2018 06:05:19 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 76CFE20850; Mon, 18 Jun 2018 12:05:17 +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 shortcircuit=ham autolearn=disabled version=3.4.0 Received: from xps13 (AAubervilliers-681-1-50-153.w90-88.abo.wanadoo.fr [90.88.168.153]) by mail.bootlin.com (Postfix) with ESMTPSA id 11744207A5; Mon, 18 Jun 2018 12:04:39 +0200 (CEST) Date: Mon, 18 Jun 2018 12:04:39 +0200 From: Miquel Raynal To: Abhishek Sahu 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 Message-ID: <20180618120439.09b41495@xps13> In-Reply-To: <7cf002e3d7ebd46476554477dd92716f@codeaurora.org> References: <1527250904-21988-1-git-send-email-absahu@codeaurora.org> <1527250904-21988-2-git-send-email-absahu@codeaurora.org> <20180526095807.5caf5800@xps13> <44d4939cf8411a0dc693b8dd11fb57c7@codeaurora.org> <20180607143759.361edb3f@xps13> <7cf002e3d7ebd46476554477dd92716f@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 Mon, 11 Jun 2018 14:46:00 +0530, Abhishek Sahu wrote: > On 2018-06-07 18:07, Miquel Raynal wrote: > > Hi Abhishek, > > > On Mon, 28 May 2018 11:16:29 +0530, Abhishek Sahu > > wrote: > > >> 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 ? > > > Yes, please :) > > > Thanks Miquel for confirming. > I will update accordingly. > > Also, one more question. > > Shall I make other functions (nand_check_ecc_caps, nand_maximize_ecc > and nand_match_ecc_req) static. Since currently, > Denali NAND driver was only using these functions. > > And Now, this nand_ecc_choose_conf will be help > in all the cases. > > For nand_check_ecc_caps: call nand_ecc_choose_conf with > chip->ecc.size && chip->ecc.strength > > For nand_maximize_ecc: call nand_ecc_choose_conf with > NAND_ECC_MAXIMIZE > > For other cases, nand_match_ecc_req will be called. > > So we will have one external function which will be > easy to maintain in future. If nobody else uses these function outside of the core, then the symbols should not be exported, their prototypes not in rawnand.h and they should be declared static. Regards, Miquèl