[PATCH] mtd: gpmi-nand: do not fail setting ONFI timing mode if available

[Boris Brezillon]

Hi Han,

Le Fri, 14 Jul 2017 14:53:39 +0000,
Han Xu <han.xu at nxp.com> a écrit :

> On 07/13/2017 03:15 PM, Boris Brezillon wrote:
> > Hi Miquel,
> >
> > Le Thu, 13 Jul 2017 21:20:30 +0200,
> > Miquel Raynal <miquel.raynal at free-electrons.com> a écrit :
> >  
> >> GPMI NFC driver fails to apply timing mode if the ->onfi_get_features()
> >> does not return the mode that was previously applied.
> >>
> >> We can assume that a nand chip supports a timing as long as it is
> >> read from the ONFI parameter page. Reading back a different mode than
> >> the one previously applied does not mean the mode is unsupported but
> >> that the nand chip does not implement the ONFI feature because it
> >> probably does not need to.
> >>
> >> The output of ->onfi_get_feature() is irrelevant so delete it.  
> > Having the NAND part that is not supporting the get/set(timing_mode)
> > feature explicitly mentioned in the commit message would help reviewers
> > understand why this patch is needed.
> >
> > Also mention that, even though the SET/GET_FEATURES(timing_mode) is
> > marked as required in the ONFI spec, this Macronix chip does not
> > support it which could be considered as a bug.
> >
> > Regards,
> >
> > Boris  
> 
> Yes, this is a Macronix chip bug and I have reproduced on my side, 
> ignoring the GET_FEATURE checking is a workaround and the chip will 
> still works in EDO mode 5, but I don't accept to remove the reasonable 
> checking code for a chip bug.

I understand why you're reluctant to remove this check just to make
one particular chip work correctly, but, on the other hand, if we were
only supporting non-broken NAND chip in mainline, plenty of boards
wouldn't be supported. Flash vendors tend to take liberties with
standards, that's a fact, and once the chip is out there's nothing we
can do about it, except add a workaround to support it.

So let's try to find a solution that makes everyone happy: now that we
have nand_manufacturer_ops, we can easily let manufacturer code flag
specific chip features as broken and let the core or drivers test for
it before using the feature.
This way, the gpmi-nand driver could check this flag before trying to
call ->onfi_set/get_features(TIMING).
Would that work for you?

BTW, that'd be great to have this driver converted to the
->setup_data_interface() approach at some point.

Regards,

Boris

> 
> >> Signed-off-by: Miquel Raynal <miquel.raynal at free-electrons.com>
> >> ---
> >>   drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 7 -------
> >>   1 file changed, 7 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> >> index 141bd70a49c2..4d137145439c 100644
> >> --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> >> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> >> @@ -939,13 +939,6 @@ static int enable_edo_mode(struct gpmi_nand_data *this, int mode)
> >>   	if (ret)
> >>   		goto err_out;
> >>   
> >> -	/* [2] send GET FEATURE command to double-check the timing mode */
> >> -	memset(feature, 0, ONFI_SUBFEATURE_PARAM_LEN);
> >> -	ret = nand->onfi_get_features(mtd, nand,
> >> -				ONFI_FEATURE_ADDR_TIMING_MODE, feature);
> >> -	if (ret || feature[0] != mode)
> >> -		goto err_out;
> >> -
> >>   	nand->select_chip(mtd, -1);
> >>   
> >>   	/* [3] set the main IO clock, 100MHz for mode 5, 80MHz for mode 4. */