From: Heiko Thiery <heiko.thiery@gmail.com>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Tudor.Ambarus@microchip.com, Michael Walle <michael@walle.cc>,
p.yadav@ti.com, ycllin@mxic.com.tw, zhengxunli@mxic.com.tw,
juliensu@mxic.com.tw, linux-mtd@lists.infradead.org
Subject: Re: spi-nor: maxronix MX25L12835F support
Date: Thu, 4 Mar 2021 08:10:03 +0100 [thread overview]
Message-ID: <CAEyMn7b+vHNiSRJTP2Qs3doK2n3xgCQm9YFBCYEn09GWLehQ0Q@mail.gmail.com> (raw)
In-Reply-To: <5ea9c0cb-3281-7bfd-e2b1-8217eff94c20@ti.com>
Hi Vignesh,
Am Do., 4. März 2021 um 08:02 Uhr schrieb Vignesh Raghavendra <vigneshr@ti.com>:
>
>
>
> On 3/3/21 7:14 PM, Heiko Thiery wrote:
> > Hi Vignesh,
> >
> [...]
> >>>>>
> >>>>> How about naming them something like "updated-flash-name ||
> >>>>> first-name".
> >>>>> Anyway, these are just workarounds. Manufacturers shouldn't use the
> >>>>> same
> >>>>> JEDEC ID for new flashes. They should at least add an extended ID.
> >>>>
> >>>> Mh, what about a list of names? I mean yes it is a workaround, but
> >>>> there is actual hardware doing this, so IMHO linux has to deal with
> >>>> it in some way. OTOH that list might be long and doesn't look good
> >>>> in dmesg (or wherever that string might be used).
> >>>>
> >>>> It might come in handy to have a mechanism in place if someone
> >>>> really cares about it though.
> >>>>
> >>>
> >>> A list of names with differentiation at run-time, where possible,
> >>> sounds good. Otherwise we'll stick to a default name, whatever that
> >>> will be. Do you care to scratch a patch for the list of names idea?
> >>>
> >>> We'll still have a single flash entry, with a list of names, and we
> >>> still need to either do the SFDP detection first, or to trigger the
> >>> SFDP detection with an explicit flash info flag. I'll follow Pratyush's
> >>> steps and evaluate the "detect SFDP first" idea.
> >>>
> >>
> >> If we do go down the road of "detect SFDP first", we should add
> >> SPI_NOR_SKIP_SFDP to flashes that currently don't claim DUAL/QUAD/OCTAL
> >> capability currently in order to avoid any surprises due to wrong values
> >> in the table.
> >
> > Does this mean that all entries that have DUAL/QUAD/OCTAL defined can
> > have them removed And the correct values will be detected/set by SFDP?
> >
>
> No, not all Dual/Quad/Octal SPI flashes have SFDP tables populated.
> Removing DUAL/QUAD/OCTAL capabilities for a flash that does not have
> SFDP tables populated (or has wrong values) will cause regression as
> code may fallback to legacy SPI mode.
So in that case removing the flags can only be done on chips/flashes
that are checked and reviewed for a valid functional SFDP detection.
--
Heiko
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-03-04 7:12 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
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 [this message]
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=CAEyMn7b+vHNiSRJTP2Qs3doK2n3xgCQm9YFBCYEn09GWLehQ0Q@mail.gmail.com \
--to=heiko.thiery@gmail.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=juliensu@mxic.com.tw \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=p.yadav@ti.com \
--cc=vigneshr@ti.com \
--cc=ycllin@mxic.com.tw \
--cc=zhengxunli@mxic.com.tw \
/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.