[PATCH v2] mtd: spi-nor: fixed spansion quad enable

Cyrille Pitchen cyrille.pitchen at atmel.com
Wed Nov 23 02:39:21 PST 2016


Hi Joel,

Le 22/11/2016 à 23:24, Joël Esponde a écrit :
> With the S25FL127S nor flash part, each writing to the configuration register takes hundreds of ms. During that  time, no more accesses to the flash should be done (even reads).
> 
> This commit adds a wait loop after the register writing until the flash finishes its work.
> 
> This issue could make rootfs mounting fail when the latter was done too much closely to this quad enable bit setting step. And in this case, a driver as UBIFS may try to recover the filesystem and may broke it completely.

Just few formal remarks about common usage and according to
Documentation/process/submitting-patches.rst:
- The summary phrase of the subject line should describe changes in imperative
  mood, so please use something like
  "mtd: spi-nor: fix spansion_quad_enable..." instead of
  "mtd: spi-nor: fixED spansion_quad_enable...".
- The commit message should be line wrapped at 75 columns.
- You must add your "Signed-off-by:". It is mandatory to know who's introduced
  the commit when browsing the logs.

> ---
>  drivers/mtd/spi-nor/spi-nor.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index d0fc165..a945122 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1255,7 +1255,11 @@ static int spansion_quad_enable(struct spi_nor *nor)
>  		return -EINVAL;
>  	}
>  
> -	/* read back and check it */
> +	ret = spi_nor_wait_till_ready(nor);
> +	if (ret)
I agree this is not done in macronix_quad_enable() but maybe a dev_err()
message may notify about the reason of the failure, just like what is done
for write_sr_cr() and read_cr().
This point is optional!

> +		return ret;
> +	
It seems there is a tab at the beginning of the empty line above.

> +	/* read CR and check it */
Your patch deals with the missing call of spi_nor_wait_till_ready() so
there is no strong reason to also modify the comment about read_cr().
The general idea is to make the patch modify only what needs to be.

>  	ret = read_cr(nor);
>  	if (!(ret > 0 && (ret & CR_QUAD_EN_SPAN))) {
>  		dev_err(nor->dev, "Spansion Quad bit not set\n");
> 

Finally, it may help you to run the scripts/checkpatch.pl tool on your patch
so this script reports you any warnings and errors in the syntax before
submitting your patch.

Best regards,

Cyrille



More information about the linux-mtd mailing list