Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp699764ybm; Tue, 21 May 2019 01:55:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqzvdrZNArhdsfszuNLTB6ZyJL9T1/06ww9TFj7z4KHJvLcx9mShji7/2br22YN6xMs5xnw+ X-Received: by 2002:a65:52c3:: with SMTP id z3mr28105034pgp.56.1558428925670; Tue, 21 May 2019 01:55:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558428925; cv=none; d=google.com; s=arc-20160816; b=GhBBOXMLUxoWQtgwbILWvYorPhNwByC+aKh3oa4w0z/oZ25wb0JumGyDPL1IzqYNNr nwXtTZgyU7HxHO9APbPjOnHdYok7RyjSKW3ROaKbI8rpCbYM0wcSuD+8n0C/tSW4XoSR f0DHUem+VeOdIwungRBCIG/E46QyB6Ct34CXvL7T3//4HAKkGVnBlF8VqAYm7XWUhqzC dQ7kQhjN6ogfn/4Oa1L4svq+/MSOT82kJ8Z8IXPsVDBmwQTyK/Fx8CGViOztd3vCm2n3 E1t9GoVxeuPbQRTuZENtR+W7npxIRy4ck/FzM27GNmQ43dfYVJK5eQZXHFCATKdQY9XR BRog== 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=lbrQPnrgmlKPfnUmCfCow1QqmkxNUnMQMiGZNw07O48=; b=E9KSrC0cpWP7cCObKBHhr75kjzY2m5jPfLfS56VJsqsArapENvgeZBESoGeGLmwnXR MSAoXCjC8smTqYNwIpFZj4OSshWpzpYQFWeC2a1uIaimUW1VQTICNPWuCrTpRR40BPmB wsX32wqXHmYLjNm5nyS3LuyfKbUgyevkgJXtYNHpngATNaqo3cKlcvdU54tQt1IZgaVn hV6D0aPZZ/bdWLZw1r1bBRY9GpoBZjJkC6vXi/iDIiBgS71TfZGKiJ+ffy0wJlnzqllD dvJv0sHWeQnMGAw9U/9U5nrySGVEZZ8i0aOSfMFku+7jeyEzX7XMA5w2DRrTaIC3Qjal Cx1Q== 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 d9si19385310plo.395.2019.05.21.01.55.10; Tue, 21 May 2019 01:55:25 -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 S1726969AbfEUIxG convert rfc822-to-8bit (ORCPT + 99 others); Tue, 21 May 2019 04:53:06 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:40947 "EHLO relay7-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726347AbfEUIxG (ORCPT ); Tue, 21 May 2019 04:53:06 -0400 X-Originating-IP: 90.88.22.185 Received: from xps13 (aaubervilliers-681-1-80-185.w90-88.abo.wanadoo.fr [90.88.22.185]) (Authenticated sender: miquel.raynal@bootlin.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id AD52520003; Tue, 21 May 2019 08:53:02 +0000 (UTC) Date: Tue, 21 May 2019 10:53:01 +0200 From: Miquel Raynal To: Florian Fainelli Cc: Kamal Dasu , linux-mtd@lists.infradead.org, bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org, Brian Norris , Richard Weinberger , David Woodhouse , Marek Vasut , Vignesh Raghavendra Subject: Re: [PATCH v2 2/2] mtd: nand: raw: brcmnand: fallback to detected ecc-strength, ecc-step-size Message-ID: <20190521105301.26e049b5@xps13> In-Reply-To: <63bbd3eb-60c1-042c-633c-cfa6fbef528c@gmail.com> References: <1558379144-28283-1-git-send-email-kdasu.kdev@gmail.com> <1558379144-28283-2-git-send-email-kdasu.kdev@gmail.com> <63bbd3eb-60c1-042c-633c-cfa6fbef528c@gmail.com> 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 Florian, Florian Fainelli wrote on Mon, 20 May 2019 12:11:42 -0700: > On 5/20/19 12:05 PM, Kamal Dasu wrote: > > This change supports nand-ecc-step-size and nand-ecc-strength fields in > > brcmnand DT node to be optional. > > 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, raw NAND layer does detect ECC information by > > reading ONFI extended parameter page for parts using ONFI >= 2.1. > > In case of non-ONFI NAND parts there could be a nand_id table entry with > > ECC information. If there is 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 | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > > index ce0b8ff..a4d2057 100644 > > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c > > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > > @@ -2144,6 +2144,17 @@ static int brcmnand_setup_dev(struct brcmnand_host *host) > > return -EINVAL; > > } > > > > + if (chip->ecc.mode != NAND_ECC_NONE && > > + (!chip->ecc.size || !chip->ecc.strength)) { > > + if (chip->base.eccreq.step_size && chip->base.eccreq.strength) { > > + /* use detected ECC parameters */ > > + chip->ecc.size = chip->base.eccreq.step_size; > > + chip->ecc.strength = chip->base.eccreq.strength; > > + pr_info("Using ECC step-size %d, strength %d\n", > > + chip->ecc.size, chip->ecc.strength); > > Nit: should not we use dev_info(&host->pdev->dev) for printing the > message in case we have multiple NAND controllers on chip, that way we > can still differentiate them from the prints? Yes, that would fit what the rest of the driver does. After that I think the patchset will be ready. Thanks, Miquèl