Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4694854yba; Wed, 10 Apr 2019 03:00:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqweC/zFzDFjnH1stPjJ8mO/tqOxd5yvhRWhIjJh/kc/N3a1QgtAHNlklr1g6NWhdqbcncrf X-Received: by 2002:a17:902:b617:: with SMTP id b23mr41318171pls.73.1554890411251; Wed, 10 Apr 2019 03:00:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554890411; cv=none; d=google.com; s=arc-20160816; b=hsOkVaxNo2wecdDD9OUMEn880xDWLQ7f9Yg6kg9oLvTw/Nvf26E1k3z28Zi48fOtwA h0GWmU6buWVdWYwRLJ+xJ0yOqI3M/Lvt0cVu/YSqZeaZ70IYv0hWbGVtzyE4uZ5eJCWV I4sfyy7hfom2UVPr/wNW84axk4wYdvW48fnwNwaCw0tAvKC/xQnpnvE4dYtX+K9pdTzg emg1moWa3RmcUCyTeOWKHXZc9cnR0r9aEVozUzl21k1RJ6Eo1RIYPb7wMqE4mpP4JZrl e+ZJRJPDrahrMJuTSFstgyMNsFWA7aQKoBdHl2eK0c2QKbPW5XFBlkKcCwgYH0wjnbVk 2y/g== 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=d4wGdNUwIvLEXSoENKORXjhCR69KFEWbN1fhxOXeTk4=; b=uexd8/WYuy7p+tj1z34z7jrUD2u+RsTeTKeul6gdAq1DxZvY9Ag5r9GIqJxzU48/bB 6jwRraATKzbZveJaMAa414zDctieY1ANZ58IkMCjrH49NXN2natwPZwbnrBCG6u52q+L 79P//lL+vtybw/dJWxCGsgXi8qeBt8keXQmE92Kma489aoMdOIdW5xmKlZIYH7YQU0tL e2MkB84l8AS9t7PfluzkzZZpnxUKEgY600Acjy2T6xqV+7M++g5PRi0ugF1nFcw/z4gX k4sJXLrd3XW3okAui09IHgqES9jvb9QnzZlSTQMlcqA+BjnOHwcRG2l4J4pLCpiDF6bT p+pQ== 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 r80si32601315pfa.128.2019.04.10.02.59.55; Wed, 10 Apr 2019 03:00:11 -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 S1729295AbfDJJP2 convert rfc822-to-8bit (ORCPT + 99 others); Wed, 10 Apr 2019 05:15:28 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:37561 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727263AbfDJJP2 (ORCPT ); Wed, 10 Apr 2019 05:15:28 -0400 Received: from xps13 (aaubervilliers-681-1-63-121.w90-88.abo.wanadoo.fr [90.88.18.121]) (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 9ABAA10000A; Wed, 10 Apr 2019 09:15:22 +0000 (UTC) Date: Wed, 10 Apr 2019 11:15:21 +0200 From: Miquel Raynal To: masonccyang@mxic.com.tw Cc: bbrezillon@kernel.org, "Boris Brezillon" , computersforpeace@gmail.com, dwmw2@infradead.org, juliensu@mxic.com.tw, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, marek.vasut@gmail.com, richard@nod.at, zhengxunli@mxic.com.tw Subject: Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer support Message-ID: <20190410111521.026c7010@xps13> In-Reply-To: References: <1554780172-23111-1-git-send-email-masonccyang@mxic.com.tw> <20190409090427.22de9917@collabora.com> <20190409114701.744c2c8c@collabora.com> <20190410091612.229c91b4@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 masonccyang@mxic.com.tw, masonccyang@mxic.com.tw wrote on Wed, 10 Apr 2019 16:40:25 +0800: > Hi Miquel, > > > > > > > > > Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and > randomizer > > > support > > > > > > > > On Tue, 9 Apr 2019 17:35:39 +0800 > > > > masonccyang@mxic.com.tw wrote: > > > > > > > > > > > + > > > > > > > +static const struct kobj_attribute sysfs_mxic_nand = > > > > > > > + __ATTR(nand_random, S_IRUGO | S_IWUSR, > > > > > > > + mxic_nand_rand_type_show, > > > > > > > + mxic_nand_rand_type_store); > > > > > > > > > > > > No, we don't want to expose that through a sysfs file, > especially > > > since > > > > > > changing the randomizer config means making the NAND unreadable > for > > > > > > those that have used it before the change. > > > > > > > > > > > > > > > > Our on-die randomizer is still readable from user after the > function > > > > > is enabled. > > > > > > > > You mean the memory is still readable no matter the randomizer > state. > > > > Not sure how that's possible, but okay. > > > > So if you write non-randomized data to the NAND chip, then enable the > > randomizer en read back the data, all will be ok? s/en/and/ > > yes ! I don't understand how this is possible. Have you tried it yourself? Can you explain how this is supposed to work? > > > > > And if randomized data is written to the NAND chip and we disable the > > randomizer, then the data will also be correct? > > > > Enable randomizer is a OTP(One-Time-Program) bit and can't be erased > again! > That means never disable it once it has been enabled. > > > > > > > > > > This randomizer is just like a internal memory cell > > > > > reliability enhanced. > > > > > > > > Why don't you enable it by default then? > > > > > > The penalty of randomizer is read/write performance down. > > > i.e,. tPROG 300 us to 340 us (randomizer enable) > > > therefore, disable it by default. > > > > Is this info somewhere in the ONFI param page? I suppose once > > randomization is enabled we should also tweak the timings and verify > > that the controller supports it. > > yes, it is in ONFI param page@Byte# 167 of bit 1 (Vendor Blocks > starting@Byte# 164). > > +#define ONFI_FEATURE_ADDR_MXIC_RANDOMIZER 0xB0 > + > +struct nand_onfi_vendor_macronix { > + u8 reserved[1]; > + u8 reliability_func; > +} __packed; > > > in addition, enable randomizer has no any impact on timing of tRC, tRP, > tWC and so on. > host driver just need to check the status pin of RY/#BY as like standard > read/write operation flow. > > thanks & best regards, > Mason > Thanks, Miquèl