From: Esben Haabendal <esben@geanix.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: linux-mtd@lists.infradead.org,
Frieder Schrempf <frieder.schrempf@kontron.de>,
Boris Brezillon <bbrezillon@kernel.org>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
Michael Walle <michael@walle.cc>, Pratyush Yadav <p.yadav@ti.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/3] mtd: spi-nor: dealing with reused JEDEC id c22016
Date: Tue, 22 Jun 2021 11:26:55 +0200 [thread overview]
Message-ID: <8735taxna8.fsf@geanix.com> (raw)
In-Reply-To: <20210621152320.3811194-1-linux@rasmusvillemoes.dk> (Rasmus Villemoes's message of "Mon, 21 Jun 2021 17:23:17 +0200")
Rasmus Villemoes <linux@rasmusvillemoes.dk> writes:
> We use the Macronix chip mx25l3233f in a number of
> products.
>
> Unfortunately, it has the same JEDEC id as another chip which is
> already listed in macronix_parts[]. Since that other one does not
> support SFDP, and its data sheet warns against issuing commands not
> explicitly listed, we can't just do RDSFDP anyway and decide that it's
> an mx25l3205d when the chip returns garbage.
>
> For lack of better alternative, start allowing multiple entries with
> the same JEDEC id in the parts tables. That allows a correctly written
> device tree to specify the right chip, without being overruled by the
> "JEDEC knows better" heuristic, while being backwards-compatible (as
> long as new chips with recycled ids get added after the existing
> ones).
>
> While a step forward, this isn't quite a complete solution for our case:
>
> Some of our platforms are based on LS1021A, thus using the
> spi-fsl-qspi driver. Back in the 4.19 kernel, when the driver was
> fsl-quadspi, we couldn't get the flash recognized unless we
> monkey-patch-replaced the mx25l3205d entry with the mx25l3233f one
> (i.e. added the SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ bits) - we'd
> fail in spi_nor_select_read() because
> shared_hwcaps&SNOR_HWCAPS_READ_MASK would be empty. In contrast, with
> current master, the chip works with or without the third patch in this
> series, i.e. whether it is detected as a mx25l3205d or mx25l3233f. But
> the read performance is ~3 times worse than in our patched 4.19 - I
> haven't quite figured out why quad read doesn't seem to be used or
> work.
>
>
> Rasmus Villemoes (3):
> mtd: spi-nor: core: create helper to compare JEDEC id to struct
> flash_info
> mtd: spi-nor: core: compare JEDEC bytes to already found flash_info
> mtd: spi-nor: macronix: add entry for mx25l3233f
>
> drivers/mtd/spi-nor/core.c | 18 +++++++++++++-----
> drivers/mtd/spi-nor/macronix.c | 3 +++
> 2 files changed, 16 insertions(+), 5 deletions(-)
For whole series:
Acked-by: Esben Haabendal <esben@geanix.com>
prev parent reply other threads:[~2021-06-22 9:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-21 15:23 [RFC 0/3] mtd: spi-nor: dealing with reused JEDEC id c22016 Rasmus Villemoes
2021-06-21 15:23 ` [RFC 1/3] mtd: spi-nor: core: create helper to compare JEDEC id to struct flash_info Rasmus Villemoes
2021-06-21 15:23 ` [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already found flash_info Rasmus Villemoes
2021-06-22 11:57 ` Michael Walle
2021-06-22 20:58 ` Rasmus Villemoes
2021-06-23 6:46 ` Tudor.Ambarus
2021-07-02 13:17 ` Rasmus Villemoes
2021-07-02 13:34 ` Tudor.Ambarus
[not found] ` <OF7CD5328D.D33B2BE2-ON482586FD.0027BCF2-482586FD.00280249@mxic.com.tw>
2021-06-23 8:33 ` 回信: " Tudor.Ambarus
2021-06-29 7:42 ` Rasmus Villemoes
2021-06-21 15:23 ` [RFC 3/3] mtd: spi-nor: macronix: add entry for mx25l3233f Rasmus Villemoes
2021-06-22 8:55 ` [RFC 0/3] mtd: spi-nor: dealing with reused JEDEC id c22016 Rasmus Villemoes
2021-06-22 9:26 ` Esben Haabendal [this message]
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=8735taxna8.fsf@geanix.com \
--to=esben@geanix.com \
--cc=bbrezillon@kernel.org \
--cc=frieder.schrempf@kontron.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@rasmusvillemoes.dk \
--cc=michael@walle.cc \
--cc=p.yadav@ti.com \
--cc=tudor.ambarus@microchip.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).