Received: by 2002:a17:90a:2044:0:0:0:0 with SMTP id n62csp532120pjc; Mon, 20 May 2019 11:21:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqy9F/8Fj1sm+a0/S4JDHhuDwhh3JVvk2BbwN//b8uAFqJ+bmaPg8Qi//qmw5Fz7nor+cICw X-Received: by 2002:a63:fb01:: with SMTP id o1mr76670975pgh.135.1558376494940; Mon, 20 May 2019 11:21:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558376494; cv=none; d=google.com; s=arc-20160816; b=TV0D03gYV3IrUc19dy2vi5FvXOaTgPyEz5DkDMLDtfpp5AJJz4ls5UF4sPCO58H/96 dXIYqeHz6kjn9jgQwuhV9cxcNJas+RhrqkXv9FvytYFLmQ2sm61esJ3FS9nRZheL+Roy hbOOQmQN7AKOoJCF8crg2TTfVpCl9W1Jjn+H7qIqwbjbZibpim/lz2K90qjBe3wug+0N rjRen2kecmJfn6zsfneu0C8YzWT/u4XpLd4roehP/tQ4PZb7HW2ZGbk6KdpP7iGKdd7r UmN2prnbmezRdhqKrQ36yNXK6I32hSnWUJhfOUcKmZ0c74Bsff0IgLpNozhXkXJDZwGB dP/A== 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; bh=zyXWnBTJD9MR1VpfITaLkbqEKJq6wQw71SmjuhbExj0=; b=PD08IyrxQmf6NRVMMDRCsDlAMy+R0/qY89L9Kls3cbbDZcxuvIm3Tg5E0UYzM7TwqO CLT7p78TtiGherv9mY9S/xxx0r6PLaRZdcT8dHb1zxeWZit+I01NH8qE+S5nvZWvRgw3 UG1qU32zFSHfF/S6ZdkMsPvhUt5r5A/ckSNK+RvivxzX5c/4HH4w2vi9modTwpi17Yz4 zepiwbSM9CaMmxdhNB7gBHm1p0MB9OEHjVVOaYGiIyFEzRZCoOB9aSNU9bXClxdtSIj9 JMGbeYECbAPgwegowu9M7Zm6uuWsoNQKnFSLAVD26zcs/3NCTsKk3yYs+I8y9AbVA17h enoQ== 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 i189si19936445pfb.41.2019.05.20.11.21.19; Mon, 20 May 2019 11:21: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 S2392920AbfETRem convert rfc822-to-8bit (ORCPT + 99 others); Mon, 20 May 2019 13:34:42 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:58555 "EHLO relay5-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392771AbfETRem (ORCPT ); Mon, 20 May 2019 13:34:42 -0400 X-Originating-IP: 91.224.148.103 Received: from xps13 (unknown [91.224.148.103]) (Authenticated sender: miquel.raynal@bootlin.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id E76121C0002; Mon, 20 May 2019 17:34:36 +0000 (UTC) Date: Mon, 20 May 2019 19:34:32 +0200 From: Miquel Raynal To: Kamal Dasu Cc: MTD Maling List , bcm-kernel-feedback-list@broadcom.com, Linux Kernel Mailing List , Brian Norris , Richard Weinberger , David Woodhouse , Marek Vasut , Vignesh Raghavendra Subject: Re: [PATCH 2/2] mtd: nand: raw: brcmnand: fallback to detected ecc-strength, ecc-step-size Message-ID: <20190520193432.79cf132f@xps13> In-Reply-To: References: <1558117914-35807-1-git-send-email-kdasu.kdev@gmail.com> <1558117914-35807-2-git-send-email-kdasu.kdev@gmail.com> <20190520144436.67e42f00@xps13> Organization: Bootlin X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; 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 Kamal, Kamal Dasu wrote on Mon, 20 May 2019 13:31:52 -0400: > Will make the changes and send a V2 patch. > > On Mon, May 20, 2019 at 8:44 AM Miquel Raynal wrote: > > > > Hi Kamal, > > > > Kamal Dasu wrote on Fri, 17 May 2019 14:29:55 > > -0400: > > > > > This change supports nand-ecc-step-size and nand-ecc-strenght fields in > > > > strength > > > > > brcmnand dt node to be optional. > > > > DT ^ extra space > > > > > see: Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > > > > > > If both nand-ecc-strength and nand-ecc-step-size are not specified in > > > device tree node for NAND, nand_base driver does detect onfi ext ecc > > > > s/nand_base driver/the raw NAND layer/ > > s/onfi/ONFI/ > > s/ecc/ECC/ > > > > What is "ext"? Please use plain English here. > > > > > info from ONFI extended parameter page for parts using ONFI >= 2.1. In > > > > s/info/information/ > > > > > case of non-onfi NAND there could be a nand_id table entry with the ecc > > > > s/ecc/ECC/ > > > > > info. If there is a valid device tree entry for nand-ecc-strength and > > > nand-ecc-step-size fields it still shall override the detected values. > > > > > > Signed-off-by: Kamal Dasu > > > --- > > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > > > index ce0b8ff..e967b30 100644 > > > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c > > > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > > > @@ -2144,6 +2144,16 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) > > > return -EINVAL; > > > } > > > > > > + if (!(chip->ecc.size > 0 && chip->ecc.strength > 0) && > > > > Is the case where only size OR strength is valid handled? > > Both strength and need to be valid, else the driver will behave like > before and will fail the probe. Yes, but you do not handle the case when either strength OR size is not valid but the other one is. Is it one purpose? > > > > > > + (chip->base.eccreq.strength > 0 && > > > + chip->base.eccreq.step_size > 0)) { > > > + /* use detected ecc parameters */ > > > > Use ECC > > > > > + chip->ecc.size = chip->base.eccreq.step_size; > > > + chip->ecc.strength = chip->base.eccreq.strength; > > > + pr_info("Using detected nand-ecc-step-size %d, nand-ecc-strength %d\n", > > > + chip->ecc.size, chip->ecc.strength); > > > + } > > > + > > > switch (chip->ecc.size) { > > > case 512: > > > if (chip->ecc.algo == NAND_ECC_HAMMING) > > > > > > Thanks, > > Miquèl > > Kamal Thanks, Miquèl