[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