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

Esponde, Joel Joel.Esponde at Honeywell.com
Mon Oct 24 01:33:11 PDT 2016


Hi Cyrille,

> -----Message d'origine-----
> De : Cyrille Pitchen [mailto:cyrille.pitchen at atmel.com]
> Envoyé : vendredi 21 octobre 2016 14:50
> À : Esponde, Joel <Joel.Esponde at Honeywell.com>; linux-
> mtd at lists.infradead.org
> Objet : Re: [PATCH] mtd: spi-nor: fixed spansion quad enable
> 
> >>> +	/* set SR & CR, enable quad I/O */
> >>>  	write_enable(nor);
> >>>
> >>>  	ret = write_sr_cr(nor, quad_en);
> >>>  	if (ret < 0) {
> >>> -		dev_err(nor->dev,
> >>> -			"error while writing configuration register\n");
> >>> +		dev_err(nor->dev, "error while writing SR and CR
> >> registers\n");
> >>>  		return -EINVAL;
> >>>  	}
> >>>
> >>> -	/* read back and check it */
> >>> +	ret = spi_nor_wait_till_ready(nor);
> >>> +	if (ret)
> >>> +		return ret;
> >>> +
> >
> > I think that this wait is required with every memories that store Quad
> Enable bit in a non-volatile way.
> > I am using today a stripped down kernel with a rootfs based on UBIFS.
> > When this bit is set, UBIFS will start reading the memory 100ms after.
> > As this bit writing step takes up to 200ms, spansion memory is not ready
> and UBIFS will fail when trying to read the content of the partition.
> > As UBIFS has a recovery mechanism, it will even broke the file system.
> >
> 
> I agree with you about adding the spi_nor_wait_till_ready() call. I plan to add
> it in my SFDP patch for the spansion_new_quad_enable(), if not done yet.
> 

Good news !!
Because I think that this part of the patch is the most critical.
Without this, you may broke your filesystem so this is a big issue.

Best regards,

Joël




More information about the linux-mtd mailing list