spi-nor: maxronix MX25L12835F support
Pratyush Yadav
p.yadav at ti.com
Tue Feb 16 05:20:29 EST 2021
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?
Dunno...
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
More information about the linux-mtd
mailing list