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;
Date:   Tue, 9 Apr 2019 11:47:01 +0200
From:   Boris Brezillon <boris.brezillon@collabora.com>
To:     masonccyang@mxic.com.tw
Cc:     bbrezillon@kernel.org, computersforpeace@gmail.com,
        dwmw2@infradead.org, juliensu@mxic.com.tw,
        linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
        marek.vasut@gmail.com, miquel.raynal@bootlin.com, richard@nod.at,
        zhengxunli@mxic.com.tw
Subject: Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and
 randomizer support
Message-ID: <20190409114701.744c2c8c@collabora.com>
In-Reply-To: <OF6C97E4DE.45261545-ON482583D7.00340468-482583D7.0034B3FE@mxic.com.tw>
References: <1554780172-23111-1-git-send-email-masonccyang@mxic.com.tw>
        <20190409090427.22de9917@collabora.com>
        <OF6C97E4DE.45261545-ON482583D7.00340468-482583D7.0034B3FE@mxic.com.tw>
Organization: Collabora
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

> This randomizer is just like a internal memory cell 
> reliability enhanced.

Why don't you enable it by default then?

> It could be enable at any time with OTP bit function and that's why
> we patch it by sys-fs.

Sorry, but that's not a good reason to expose that through sysfs.