spi-nor: maxronix MX25L12835F support

Heiko Thiery heiko.thiery at gmail.com
Tue Feb 16 05:41:08 EST 2021


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?

-- 
Heiko



More information about the linux-mtd mailing list