spi-nor: maxronix MX25L12835F support

[Heiko Thiery]

Hi,

Am Di., 16. Feb. 2021 um 11:48 Uhr schrieb Pratyush Yadav <p.yadav at ti.com>:
>
> On 16/02/21 11:41AM, Heiko Thiery wrote:
> > Hi,
> >
> > Am Di., 16. Feb. 2021 um 11:20 Uhr schrieb Pratyush Yadav <p.yadav at ti.com>:
> > >
> > > On 16/02/21 03:46PM, Pratyush Yadav wrote:
> > > > On 16/02/21 10:48AM, Michael Walle wrote:
> > > > > 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?
> > > > > >
> > > > > > 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.
> > > >
> > > > Is it possible to differentiate between the two flashes in any way? If
> > > > so you can use the init_params() fixup to check that add the flags for
> > > > the new flash. Modifying nor->info feels kind of wrong but it is an
> > > > acceptable compromise in this situation IMO.
> > >
> > > I take that back. nor->info is declared as const and let's keep it that
> > > way. Maybe you can add something in nor->flags to indicate we want to
> > > parse SFDP? Or maybe there is some other way to indicate SFDP support?
> >
> > That was also my intention. I thought about something like
> > SPI_NOR_FORCE_SFDP. But what will happen if we try to parse and the
> > legacy device does not support SFDP read?
>
> Most likely it will not do anything and SFDP parsing will fail because
> it can't find the SFDP signature. But let's try to avoid that if
> possible. Is it possible to differentiate between the two flashes in any
> way? If it is possible, then just set the flag for the new device and
> leave the legacy device alone.

Is there a good reason not to do the SFDP parsing in general? At the
moment I have no other idea how to differentiate the two flashes.

-- 
Heiko