spi-nor: maxronix MX25L12835F support

[Pratyush Yadav]

On 16/02/21 11:55AM, Heiko Thiery wrote:
> 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.

The fact that the flash (legacy one) does not support the SFDP command 
at all is reason enough for me. Why issue commands that a flash doesn't 
support?

But if you don't manage to find anything better, I guess the SFDP 
command can be used to tell the flashes apart. But don't rely on 
spi_nor_parse_sfdp() to do so. Do it in the default_init() hook. Of 
course, details can be better fleshed out when there is an actual patch 
to read through :-)

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.