All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <p.yadav@ti.com>
To: Michael Walle <michael@walle.cc>
Cc: Heiko Thiery <heiko.thiery@gmail.com>, linux-mtd@lists.infradead.org
Subject: Re: spi-nor: maxronix MX25L12835F support
Date: Tue, 16 Feb 2021 15:50:29 +0530	[thread overview]
Message-ID: <20210216102029.uz3u6dzl2eoh5c7x@ti.com> (raw)
In-Reply-To: <20210216101603.s22b2fs7en52ximf@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? 
Dunno...

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-02-16 10:21 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 21:53 spi-nor: maxronix MX25L12835F support Heiko Thiery
2021-02-16  9:27 ` Pratyush Yadav
2021-02-16  9:45   ` Heiko Thiery
2021-02-16  9:48   ` Michael Walle
2021-02-16 10:16     ` Pratyush Yadav
2021-02-16 10:20       ` Pratyush Yadav [this message]
2021-02-16 10:41         ` Heiko Thiery
2021-02-16 10:48           ` Pratyush Yadav
2021-02-16 10:55             ` Heiko Thiery
2021-02-16 11:05               ` Pratyush Yadav
2021-02-16 11:15     ` Tudor.Ambarus
2021-02-18  5:45       ` zhengxunli
2021-02-18  7:15         ` Heiko Thiery
2021-02-18  7:56         ` Tudor.Ambarus
2021-02-18  8:49           ` Tudor.Ambarus
2021-02-18  7:43       ` Heiko Thiery
2021-02-18  9:27         ` Tudor.Ambarus
2021-02-18 10:15           ` Heiko Thiery
2021-02-18 10:26             ` Tudor.Ambarus
2021-02-18 10:36               ` Heiko Thiery
2021-02-19  2:45               ` zhengxunli
2021-02-27 21:52               ` Heiko Thiery
2021-03-01 10:52                 ` Vignesh Raghavendra
2021-03-01 11:11                   ` Tudor.Ambarus
2021-03-01 13:36                     ` Pratyush Yadav
2021-03-01 13:50                       ` Michael Walle
2021-03-01 14:09                         ` Tudor.Ambarus
2021-03-01 14:42                           ` Michael Walle
2021-03-01 15:25                             ` Tudor.Ambarus
2021-03-02  5:49                               ` Vignesh Raghavendra
2021-03-03 13:44                                 ` Heiko Thiery
2021-03-04  7:02                                   ` Vignesh Raghavendra
2021-03-04  7:10                                     ` Heiko Thiery
2021-03-19 14:33                                       ` Stefan Herbrechtsmeier
2021-03-01 15:40                         ` Pratyush Yadav
2021-03-01 14:03                       ` Tudor.Ambarus
2021-06-28  7:29 ` Tudor.Ambarus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210216102029.uz3u6dzl2eoh5c7x@ti.com \
    --to=p.yadav@ti.com \
    --cc=heiko.thiery@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.