public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.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, richard@nod.at
Subject: Re: [PATCH v1] mtd: rawnand: Add Macronix NAND read retry support
Date: Fri, 10 May 2019 11:12:36 +0200	[thread overview]
Message-ID: <20190510111121.54f42e70@xps13> (raw)
In-Reply-To: <OF5E2BF75D.98A43E33-ON482583F6.002E7A65-482583F6.0030A2DE@mxic.com.tw>

Hi Mason,

masonccyang@mxic.com.tw wrote on Fri, 10 May 2019 16:51:20 +0800:

> Hi Miquel,
> 
> 
> > > Add a driver for Macronix NAND read retry.  
> > 
> > "Add support for Macronix NAND read retry."? This is not a "new driver".
> >   
> > > 
> > > Macronix NAND supports specfical read for data recovery and enabled  
> > 
> > 
> > Macronix NANDs support specific read operation for data recovery,
> > which can be enabled with a SET_FEATURE.
> >   
> > > Driver check byte 167 of Vendor Blocks in ONFI parameter page table  
> > 
> >          checks
> >   
> > > to see if this high reliability function is support or not.  
> > 
> >                  high-reliability function? not sure it is English
> >                  anyway.
> > 
> >                                               supported
> >   
> 
> okay, thanks for your review, will patch it to:
> ------------------------------------------------------------------------
> Add support for Macronix NAND read retry.
> 
> Macronix NANDs support specific read operation for data recovery,
> which can be enabled with a SET_FEATURE.
> Driver checks byte 167 of Vendor Blocks in ONFI parameter page table
> to see if this high-reliability function is supported.
> -------------------------------------------------------------------------

Fine by me.

[...]

> > > +   int ret;
> > > +
> > > +   if (mode > MACRONIX_READ_RETRY_MODE)
> > > +      mode = MACRONIX_READ_RETRY_MODE;
> > > +
> > > +   feature[0] = mode;
> > > +   ret =  nand_set_features(chip, ONFI_FEATURE_ADDR_READ_RETRY,   
> feature);
> > 
> > Don't you miss to select/deselect the target?  
> 
> nand_select_target() and nand_deselect_target() are already in 
> nand_do_read_ops().

Right

> 
> >   
> > > +   if (ret)
> > > +      pr_err("set feature failed to read retry moded:%d\n", mode);  
> > 
> >                        "Failed to set read retry mode: %d\n"
> > 
> > I think you can abort the operation with a negative return code in this
> > case.
> >   
> 
> After set feature operation, this NAND device need a get feature command 

You need to add a comment for this.

> or
> SW reset command to exit read retry mode.
> Therefore, set features command followed by get feature command is needed.

In this case you must check first that both set and get are supported.

> 
> > > +
> > > +   ret =  nand_get_features(chip, ONFI_FEATURE_ADDR_READ_RETRY,   
> feature);
> > 
> > If the operation succeeded but the controller cannot get the feature
> > you don't want to abort the operation. You should check if get_features
> > is supported, if yes you can rely on the below test.
> >   
> 
> I thought it has been check in macronix_nand_onfi_init() and set by
> set_bit(ONFI_FEATURE_ADDR_READ_RETRY, p->get_feature_list);

You only checked that the operation can be done, you cannot know in
advance if it will actually succeed.

> 
> right ?
> 
> > > +   if (ret || feature[0] != mode)
> > > +      pr_err("get feature failed to read retry moded:%d(%d)\n",
> > > +             mode, feature[0]);  
> > 
> >                        "Failed to verify read retry mode..."
> > 
> >                 Also return something negative here.
> >   
> > > +
> > > +   return ret;  
> > 
> > And if all went right, return 0 at the end.
> >   
> > > +}
> > > +
> > > +static void macronix_nand_onfi_init(struct nand_chip *chip)
> > > +{
> > > +   struct nand_parameters *p = &chip->parameters;
> > > +
> > > +   if (p->onfi) {
> > > +      struct nand_onfi_vendor_macronix *mxic =
> > > +            (void *)p->onfi->vendor;  
> > 
> > Please put everything on the same line  
> 
> It will over 80 char.

I know, that's fine here.

> 
> >   
> > > +
> > > +      if (mxic->reliability_func & MACRONIX_READ_RETRY_BIT) {
> > > +         chip->read_retries = MACRONIX_READ_RETRY_MODE + 1;  
> > 
> > Why +1 here, I am missing something?  
> 
>  
> Without + 1, read retry mode is up to 4 rather than 5.
> But this NAND device support read retry mode up to 5.
> 

If there are 5 modes, you need to set 5 to chip->read_retries, not 6.

If only 4 modes are used, there is probably a bug in the core that
must be fixed, please do not workaround it in the driver!


Thanks,
Miquèl

  parent reply	other threads:[~2019-05-10  9:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10  7:41 [PATCH v1] mtd: rawnand: Add Macronix NAND read retry support Mason Yang
2019-05-10  7:45 ` Miquel Raynal
     [not found]   ` <OF5E2BF75D.98A43E33-ON482583F6.002E7A65-482583F6.0030A2DE@mxic.com.tw>
2019-05-10  9:12     ` Miquel Raynal [this message]
     [not found]       ` <OF3A216E48.80ABBB8A-ON482583F9.002A09DA-482583F9.002AD40E@mxic.com.tw>
2019-05-13  9:59         ` Miquel Raynal
2019-05-14  2:16           ` masonccyang
2019-05-10 13:37 ` Thomas Petazzoni
2019-05-10 13:53   ` Miquel Raynal
2019-05-10 14:18   ` Miquel Raynal
     [not found]   ` <OF1EDBA487.7723094D-ON482583F9.00297ABF-482583F9.0029E3EE@mxic.com.tw>
2019-05-13  9:40     ` Thomas Petazzoni
     [not found]       ` <OFB5D53BFC.6B44E7E0-ON482583FA.00090982-482583FA.000A5E93@mxic.com.tw>
2019-05-14  7:41         ` Thomas Petazzoni
2019-05-15  1:30           ` masonccyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190510111121.54f42e70@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=juliensu@mxic.com.tw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=masonccyang@mxic.com.tw \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox