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:   Thu, 11 Apr 2019 11:29:43 +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: <20190411112943.1fecfa69@collabora.com>
In-Reply-To: <OF34672B6F.AACFE22C-ON482583D9.00335814-482583D9.0033A673@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>
        <20190409114701.744c2c8c@collabora.com>
        <OF9601E14B.A48284C4-ON482583D8.0005E3EB-482583D8.0006CC14@mxic.com.tw>
        <20190410092258.332ef399@collabora.com>
        <OF071D3608.9D6D2523-ON482583D9.00173F52-482583D9.0018188C@mxic.com.tw>
        <20190411085353.4c1af008@collabora.com>
        <OF34672B6F.AACFE22C-ON482583D9.00335814-482583D9.0033A673@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 Thu, 11 Apr 2019 17:24:09 +0800
masonccyang@mxic.com.tw wrote:

> Hi Boris,
>  
>  
> > > > > > Subject
> > > > > > 
> > > > > > 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.
> > > > > >   
> > > > > > > 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.   
> > > > 
> > > > I'm a bit puzzled. On the NAND I've seen that required data
> > > > randomization it's not something you'd want to disable as this   
> implied
> > > > poor data retention. What's the use case here? Are we talking about   
> SLC
> > > > or MLC NANDs? Should we enable this feature once we start seeing   
> that
> > > > the NAND starts being less reliable (basically when read-retry   
> happens
> > > > more often)? I really think this is something you should decide   
> kernel
> > > > side, because users have no clue when it's appropriate to switch   
> this
> > > > feature on/off.
> > > >   
> > > 
> > > It's SLC NAND and seems to has nothing to do with read-retry happens.
> > > later, I will get more information for your concerns.  
> > 
> > Well, this feature is optional, and can be enabled to improve
> > reliability. Sounds like a good reason to enable it when your NAND
> > device starts showing reliability issues, and the number of read_retry
> > attempts reflects the wear level pretty well. Alternatively, you could
> > use the number of bitflips, but, in any case, don't expect the user to
> > take this decision, because almost nobody knows what the randomizer
> > is needed for.
> >   
> > >   
> > > > >   
> > > > > >   
> > > > > > > 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. 
> > > > > 
> > > > > Any good way to expose randomizer function for user ?   
> > > > 
> > > > Don't expose it :P.   
> > > 
> > > oh, okay, I will remove sys-fs randomizer.
> > > 
> > > Is it OK to keep set/get features for randomizer ?  
> > 
> > I don't think it's a good idea to have dead code, so no. But I'm pretty
> > sure we'll find a way to use/expose this feature.  
>  
> okay, great!
> Looking forward to hearing this feature use/expose.

But for that to happen we are waiting for inputs about when this is
supposed to be used...