spi-nor: maxronix MX25L12835F support

[Pratyush Yadav]

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.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.