spi-nor: maxronix MX25L12835F support

[Heiko Thiery]

Hi Zhengxun,

Am Do., 18. Feb. 2021 um 06:47 Uhr schrieb <zhengxunli at mxic.com.tw>:
>
> Hi,
>
> <Tudor.Ambarus at microchip.com> wrote on 2021/02/16 下午 07:15:33:
>
> > <Tudor.Ambarus at microchip.com>
> > 2021/02/16 下午 07:15
> >
> > To
> >
> > <michael at walle.cc>, <p.yadav at ti.com>, <ycllin at mxic.com.tw>,
> > <zhengxunli at mxic.com.tw>, <juliensu at mxic.com.tw>,
> >
> > cc
> >
> > <heiko.thiery at gmail.com>, <linux-mtd at lists.infradead.org>
> >
> > Subject
> >
> > Re: spi-nor: maxronix MX25L12835F support
> >
> > Hi, all,
> >
> > +zhengxunli, juliensu & ycllin
> >
> > On 2/16/21 11:48 AM, Michael Walle wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> > >
> > > Am 2021-02-16 10:27, schrieb Pratyush Yadav:
> > >> On 15/02/21 10:53PM, Heiko Thiery wrote:
> > >>> Hi all,
> > >>>
> > >>> I faced an issue with a SPI flash on our board. We use a macronix
> > >>> MX25L12835F [1]. Unfortunately this flash has the same JEDEC ID like
> > >>> the MX25L12805D [2].
> > >>>
> > >>> The newer MX25L12835F has support for dual/quad read mode and RDSFDP
> > >>> while the older doesn't.
> > >>>
> > >>> I thought that I could do a fixup with a device specific
> > >>> post_bfpt_fixups() call but by now this seems not possible. The
> older
> > >>> MX25L12805D has no flags set that allows a call to
> > >>> spi_nor_sfdp_init_params() and implements the fixup.
> > >>>
> > >>> Has anyone an idea how to solve this?
> >
> > Maybe macronix can help with some suggestions on how to differentiate
> > between flashes at runtime.
>
> In fact, the duplicate ID also caused us trouble. Maybe you can refer to
> our colleagues' patches and add a new ID before the old ID.

But doesn't that mean I have to explicitly set the right used flash
device in my dtb? Currently I have set "jedec,spi-nor" and let the
mtd/spi subsystem find the right values to use. As we have 2 other
devices as alternatives I wouldn't like to do that.

And what about the old device. Will this one be correctly configured
when detecting automatically?

>
> https://patchwork.ozlabs.org/project/linux-mtd/patch/1587631123-25474-2-git-send-email-masonccyang@mxic.com.tw/
>
> > My first thought is to introduce a SPI_NOR_HAS_SFDP flag. For the flash
> > that doesn't support SFDP tables, there should be no functional change,
> > for the one that support SFDP it should fill the properties from the
> > SFDP tables.
> >
> > >>
> > >> The post_sfdp fixup is always run regardless of whether the flash has
> > >> SFDP or not. You can try putting your flash-specific fixups there.
> > >
> > > Well the problem here is, that the SFDP setup is skipped though the
> > > flash would support SFDP. If the jedec id wasn't already in the table,
> > > there would be the flag SPI_NOR_QUAD_READ and the SFDP would be
> > > parsed. But because there is already the legacy device (which likely
> > > doesn't support SFDP) it really doesn't fit.
> > >
> > > Its unclear to me, why the SFDP is only parsed if one of the
> > > SPI_NOR_*_READ flags are set.
> >
> > My guess is that a new SFDP flag was not necessary. SFDP defines
> multiple
> > tables, but there is just one that is mandatory, BFPT. BFPT defines DUAL
> > and QUAD parameters. From the spi-nor code, a BFPT without DUAL or QUAD
> > support doesn't make sense, even though DUAL or QUAD are not mandatory
> > in BFPT as I see in the standard. So probably it was just a way to avoid
> > adding a extra flag. We have to check the git history for a more
> accurate
> > description, this was just a guess.
> >
> > Thinking loud, now we do a static initialization of flash params, that
> > can be overwritten dynamically by SFDP. How about doing the params init
> > the other way around. Try first to dynamically discover the params via
> > SFDP, and if SFDP fails or if it is not defined, do the static init via
> > flags. That would spare some code. And new flash IDs will have less
> flags
> > declared, and we'll better track faulty SFDP flashes.
> >
>
> Thanks,
> Zhengxun

Thank you
-- 
Heiko