Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1545856imm; Sun, 27 May 2018 09:32:02 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrDThJFPFeg57xDFDMs/sD3oakJ6zHpqi9sRT1tZ/8saHSCYjWnMnnnIE/UUUcvisnmBxW6 X-Received: by 2002:a17:902:205:: with SMTP id 5-v6mr10174284plc.301.1527438722430; Sun, 27 May 2018 09:32:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527438722; cv=none; d=google.com; s=arc-20160816; b=xAYsvZ71DyV6kiT+sabrh8IkdWJPWb++AoBJMVM8baKqxQApBEkGfBysXohSUmVsTQ MFv8T9BHwNmCFGaF/zSSMvziKPprroLUgnIRUJ2rdgKgOQ4BBylbP4wC6i6Jw6qapEK7 LugpY9GZhQhy+hMUQxvb4JLK7JIsBGWviOd+4D1DRK4l/P5+xiaB+HaCg25ewQPuu3JU lbzzI618Iie9HtVt/sS3LoeWRMVxGHqLkZfx7ggLUp2rV35tQwy65H64r5B/XBIlcLTU U4XH+Q58tcatnCv06nC3pgtxi1Xcwwzn0D+StP/dw/O+UUz+aWEqG0oBQMivDtPUVGv5 QMDQ== 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=C+htlcFh4/NpL3gOHWwzYn0XywDb5qYdvyjQs2KH4+Y=; b=tjYWBHGx5NCS7E1WeE47tTem1u3ey+M69aWDVD8pLY6b1hxcN3n/N8r4tDrGdTgbhD mkOvD/Ze87twsIgLNOw5D+8jNYelTGf+26wdwCMtOLRrw5qeA1wXsq19kEfNcHpZNXNj ZgzsmDoPJ9DhVOhIGxKvFFi3ZfFYxk21LZxi/3uOBWAA0X8aslhkWHyOwm+v6ftea2Uj Hx3HvPk58hrnFuN6wlrUJqk8A19AP7ZccAfob3X4siQ5wjOvEQAbEfLTsEDUHPZUnZX8 bMAJB7EgrWUnsC85x9DFQG8pFjmM1a0QOU6o408SvBtHwORjT1KHbocBP+aTTNqNFRfH Y0Gw== 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 d15-v6si8798926pgu.21.2018.05.27.09.31.14; Sun, 27 May 2018 09:32:02 -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 S1032841AbeE0QbA (ORCPT + 99 others); Sun, 27 May 2018 12:31:00 -0400 Received: from mail.bootlin.com ([62.4.15.54]:52581 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032801AbeE0Qa7 (ORCPT ); Sun, 27 May 2018 12:30:59 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 9B14C20750; Sun, 27 May 2018 18:30:57 +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 (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id DAC3F20376; Sun, 27 May 2018 18:30:56 +0200 (CEST) Date: Sun, 27 May 2018 18:30:55 +0200 From: Boris Brezillon To: Miquel Raynal Cc: Stefan Agner , Benjamin Lindqvist , dwmw2@infradead.org, computersforpeace@gmail.com, marek.vasut@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, thierry.reding@gmail.com, mturquette@baylibre.com, sboyd@kernel.org, Lucas Stach , richard@nod.at, marcel@ziswiler.com, krzk@kernel.org, digetx@gmail.com, jonathanh@nvidia.com, pdeschrijver@nvidia.com, pgaikwad@nvidia.com, Mirza Krak , linux-mtd@lists.infradead.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver Message-ID: <20180527183055.05c4d197@bbrezillon> In-Reply-To: <20180527175403.065a135d@xps13> References: <86fdf19ec92b732709732fb60199f16488b4b727.1526990589.git.stefan@agner.ch> <20180524135335.6aa0b7a4@bbrezillon> <146a3abbbff4dcef30ad662a0fb85ff1@agner.ch> <20180527161832.1152be6e@xps13> <20180527171337.002eeb9f@bbrezillon> <20180527175403.065a135d@xps13> 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 Sun, 27 May 2018 17:54:03 +0200 Miquel Raynal wrote: > Hi Boris, > > On Sun, 27 May 2018 17:13:37 +0200, Boris Brezillon > wrote: > > > On Sun, 27 May 2018 16:18:32 +0200 > > Miquel Raynal wrote: > > > > > Hi Stefan, > > > > > > On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner > > > wrote: > > > > > > > On 24.05.2018 13:53, Boris Brezillon wrote: > > > > > Hi Benjamin, > > > > > > > > > > On Thu, 24 May 2018 13:30:14 +0200 > > > > > Benjamin Lindqvist wrote: > > > > > > > > > >> Hi Stefan, > > > > >> > > > > >> It seems to me that a probe similar to what the BootROM does shouldn't > > > > >> be awfully complicated to implement - just cycle through the switch > > > > >> cases in case of an ECC error. But I guess that's more of an idea for > > > > >> further improvements rather than a comment to the patch set under > > > > >> review. > > > > > > > > > > Nope, not really an option, because you're not guaranteed that the NAND > > > > > will be used as a boot media, and the first page or first set of pages > > > > > might just be erased. > > > > > > > > > > > > > Yeah I did not meant probing like the Boot ROM does. > > > > > > > > What I meant was using only the ECC modes which are supported by the > > > > Boot ROM when the driver tries to choose a viable mode. So that would > > > > be: > > > > - RS t=4 > > > > - BCH t=8 > > > > - BCH t=16 > > > > > > > > Maybe we could add a property to enable that behavior: > > > > > > > > tegra,use-bootable-ecc-only; > > > > > > I'm not sure a property is needed. > > > > > > As there is currently no official user of this driver, why not turning > > > mandatory the nand-ecc-xxx properties? > > > > Not a big fan of this solution. We already have a few cases where the > > NAND part was changed on a design and the new NAND had different ECC > > requirements, With your suggestion, that means creating a new .dts file > > for each possible NAND part. > > > > Note that having a solution that picks the best ECC config based on > > chip->ecc_xxx_ds should be the preferred approach. nand-ecc- props are > > mainly here to address the case where you need/want to assign a config > > that does not match the ECC requirements exposed by the chip. > > Ok, that's right it's a problem. > > But then the driver has to choose a default algorithm if none is given. Yep. > In this case, should we select the one that fits best the NAND chip > requirements, or shall we limit to the ones supported by the BootRom? We should limit to the one used by the BootROM only if the NAND is used as a boot medium. > > The underlying question is: will we add a tegra,use-bootable-ecc-only > property? I guess this one is fine, because it's only adding a constraint on the possible ECC modes that can be used, it's not forcing a specific ECC strength. Note that if we want to make this property generic we could name it nand-is-boot-medium.