Received: by 10.192.165.148 with SMTP id m20csp2816275imm; Mon, 7 May 2018 01:29:07 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrQVOFTMJhzyqZcyIFfhqxEui3Pz1gTgPe71yyB5dVofKl80l8lJuzm2NzGsGDbFMaTgsNq X-Received: by 2002:a17:902:9304:: with SMTP id bc4-v6mr14673123plb.189.1525681747319; Mon, 07 May 2018 01:29:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525681747; cv=none; d=google.com; s=arc-20160816; b=uDkZm/beKqMYglN6BBmHhyoakfV+fGlU63+Zg13VwGhalTbXne/PX7vTLfNIm846e6 Iod0khKex7Z3uR1/9FrHGf/OpPnWJPgxb+R9BtJ3FzvnlYO0CfN46A1/bLUV2LVSOISE B2o/DmiQznMJaOsikKy6zM+4+SwllM57Ooi35hbrJy/YThfYs7FxMgCQGdWSGgX5ttfI rlCxxVrwHpxXHPFBg51RpklcOuHQfPjkACacyxaaO46dV5M6pKibZD7937bpV/FMVMuK keupbi38ddPXzGFwERUdiKWmh68wv2/SB0gjQjmlVxlSJfE1VpW7NHgb3mOGyvvQUMIv Ot1Q== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=km7/K3TNr7BTTMKt85ZL+bbonmZJGAF8wg7kvURH9KY=; b=bxt1jujCiVyMM23RppoKWHTBlFjfREEzsP1pdaPo3KvrOtlvd8IDRC+aaqLFMS0OlA y22qGjf2WZVF+03VHPl1Wdsg/U6SbFBEibXyuJGoPxPGtCf/ArQROvVeUfLmor13hqRR xtkp8xxhjppTRk9sAXHYmQhwZEdwnWqxL9FYUTeEuuZqQj2oCxsBwDss9+YMb1+KkqGF QSmn6v3wcZnmwRprIEPUs/XQ3WcUHhM9WLoTjR9oQ2mmCHc9sXRmeMCG4LRJ2HZfEo6/ 2sz1ZdG8SH+d1lUfFOwbRBU5mBdbXUbyyXLbd3fLTT7VmINZERL9wkBKw5Q4LbPLQQRn T9iQ== 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 36-v6si8048460plb.140.2018.05.07.01.28.52; Mon, 07 May 2018 01:29:07 -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 S1752028AbeEGI2o (ORCPT + 99 others); Mon, 7 May 2018 04:28:44 -0400 Received: from mail.bootlin.com ([62.4.15.54]:45810 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751900AbeEGI2n (ORCPT ); Mon, 7 May 2018 04:28:43 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id C84DA20714; Mon, 7 May 2018 10:28:40 +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 bbrezillon (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id 65C4520376; Mon, 7 May 2018 10:28:40 +0200 (CEST) Date: Mon, 7 May 2018 10:28:40 +0200 From: Boris Brezillon To: Abhishek Sahu Cc: Archit Taneja , Richard Weinberger , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Marek Vasut , linux-mtd@lists.infradead.org, Miquel Raynal , Andy Gross , Brian Norris , David Woodhouse Subject: Re: [PATCH v2 04/14] mtd: rawnand: qcom: use the ecc strength from device parameter Message-ID: <20180507102840.3624fe01@bbrezillon> In-Reply-To: <1525350041-22995-5-git-send-email-absahu@codeaurora.org> References: <1525350041-22995-1-git-send-email-absahu@codeaurora.org> <1525350041-22995-5-git-send-email-absahu@codeaurora.org> 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=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 May 2018 17:50:31 +0530 Abhishek Sahu wrote: > Currently the driver uses the ECC strength specified in DT. > The QPIC/EBI2 NAND supports 4 or 8-bit ECC correction. The same > kind of board can have different NAND parts so use the ECC > strength from device parameters if it is not specified in DT. > > Signed-off-by: Abhishek Sahu > --- > * Changes from v1: > > 1. Removed the custom logic and used the helper fuction. > > drivers/mtd/nand/raw/qcom_nandc.c | 31 ++++++++++++++++++++++--------- > 1 file changed, 22 insertions(+), 9 deletions(-) > > diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c > index b554fb6..a8d71ce 100644 > --- a/drivers/mtd/nand/raw/qcom_nandc.c > +++ b/drivers/mtd/nand/raw/qcom_nandc.c > @@ -2315,13 +2315,21 @@ static int qcom_nand_ooblayout_free(struct mtd_info *mtd, int section, > .free = qcom_nand_ooblayout_free, > }; > > +static int > +qcom_nandc_calc_ecc_bytes(int step_size, int strength) > +{ > + return strength == 4 ? 12 : 16; > +} > +NAND_ECC_CAPS_SINGLE(qcom_nandc_ecc_caps, qcom_nandc_calc_ecc_bytes, > + NANDC_STEP_SIZE, 4, 8); > + > static int qcom_nand_host_setup(struct qcom_nand_host *host) > { > struct nand_chip *chip = &host->chip; > struct mtd_info *mtd = nand_to_mtd(chip); > struct nand_ecc_ctrl *ecc = &chip->ecc; > struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip); > - int cwperpage, bad_block_byte; > + int cwperpage, bad_block_byte, ret; > bool wide_bus; > int ecc_mode = 1; > > @@ -2334,8 +2342,20 @@ static int qcom_nand_host_setup(struct qcom_nand_host *host) > return -EINVAL; > } > > + cwperpage = mtd->writesize / ecc->size; Looks like you're still expecting nand-ecc-step-size to be defined in the DT, which does not really make sense since you only support one size: NANDC_STEP_SIZE. You should remove the if (ecc->size != NANDC_STEP_SIZE) { dev_err(nandc->dev, "invalid ecc size\n"); return -EINVAL; } block, then do: cwperpage = mtd->writesize / NANDC_STEP_SIZE; and finally let the nand_ecc_param_setup() function choose the best config for you. > + > + /* > + * Each CW has 4 available OOB bytes which will be protected with ECC > + * so remaining bytes can be used for ECC. > + */ > + ret = nand_ecc_param_setup(chip, &qcom_nandc_ecc_caps, > + mtd->oobsize - (cwperpage << 2)); Please stop doing useless optimizations like. That brings nothing and obfuscates the code a bit more. You say in the comment that each codeword has 4 protected OOB bytes that can be used by the upper layer, so just do (cwperpage * 4) and let gcc optimize that for you. > + if (ret) { > + dev_err(nandc->dev, "No valid ecc settings possible\n"); > + return ret; > + } > + > wide_bus = chip->options & NAND_BUSWIDTH_16 ? true : false; > - > if (ecc->strength >= 8) { > /* 8 bit ECC defaults to BCH ECC on all platforms */ > host->bch_enabled = true; > @@ -2403,7 +2423,6 @@ static int qcom_nand_host_setup(struct qcom_nand_host *host) > > mtd_set_ooblayout(mtd, &qcom_nand_ooblayout_ops); > > - cwperpage = mtd->writesize / ecc->size; > nandc->max_cwperpage = max_t(unsigned int, nandc->max_cwperpage, > cwperpage); > > @@ -2419,12 +2438,6 @@ static int qcom_nand_host_setup(struct qcom_nand_host *host) > * for 8 bit ECC > */ > host->cw_size = host->cw_data + ecc->bytes; > - > - if (ecc->bytes * (mtd->writesize / ecc->size) > mtd->oobsize) { > - dev_err(nandc->dev, "ecc data doesn't fit in OOB area\n"); > - return -EINVAL; > - } > - > bad_block_byte = mtd->writesize - host->cw_size * (cwperpage - 1) + 1; > > host->cfg0 = (cwperpage - 1) << CW_PER_PAGE