From: "Michael Walle" <mwalle@kernel.org>
To: "Esben Haabendal" <esben@geanix.com>,
"Tudor Ambarus" <tudor.ambarus@linaro.org>
Cc: "Pratyush Yadav" <pratyush@kernel.org>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
"Rasmus Villemoes" <rasmus.villemoes@prevas.dk>
Subject: Re: [PATCH v2 1/2] mtd: spi-nor: core: add flag for doing optional SFDP
Date: Wed, 12 Jun 2024 10:51:11 +0200 [thread overview]
Message-ID: <D1XWS6SSXALZ.3NKR71449UYAO@kernel.org> (raw)
In-Reply-To: <87le3g283a.fsf@geanix.com>
[-- Attachment #1.1: Type: text/plain, Size: 1892 bytes --]
Hi,
On Fri Jun 7, 2024 at 3:30 PM CEST, Esben Haabendal wrote:
> But other than avoiding the "magic flags decide whether we use SFDP",
> should I be doing anything different?
>
> I assume we should still be calling the default_init() fixup functions,
> both for manufacturer and flash level. Or should we leave this for the
> deprecated case only?
No, they have to be handled.
> If the semantics is basically the same as for the deprecated, why not
> simply change the implementation of the deprecated approach to what we
> need? So having 3 cases:
>
> (1) SFDP only [indicated by size==0]
> (2) static config only [indicated by no_sfdp_flags & SPI_NOR_SKIP_SFDP]
> (3) SFDP with fallback to static config [indicated with size!=0 and
> !(no_sfdp_flags & SPI_NOR_SKIP_SFDP]
>
> Any reason that we should not be able to easily convert existing
> depracted flash info specifications to the new SFDP with fallback to
> static config?
IMHO the only difference is that dual/quad read will imply the sfdp
fallback. So maybe the function can really be renamed accordingly
and the "deprecated handling" is just that dual/quad read will set
the sfdp fallback flag.
> Also I am wondering if anyone can remember or otherwise figure out why
> we are doing this memcpy() dance with nor->params in
> spi_nor_sfdp_init_params_deprecated()? Why not simply call
> spi_nor_parse_sfdp() before
> spi_nor_no_sfdp_init_params()/spi_nor_manufacturer_init_params()?
spi_nor_parse_sfdp() will overwrite the parameters set by the former.
So if you'll swap the order, the latter (static) ones will overwrite
the the ones from sfdp.
The correct fix would be to make spi_nor_parse_sfdp() not fiddle
around the parameters if it might fail. The quick fix here might be
to push that memcpy into the parse function. But I haven't looked at
the code right now.
-michael
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2024-06-12 8:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 13:09 [PATCH v2 0/2] mtd: spi-nor: macronix: workaround for device id re-use Esben Haabendal
2024-06-03 13:09 ` [PATCH v2 1/2] mtd: spi-nor: core: add flag for doing optional SFDP Esben Haabendal
2024-06-06 13:31 ` Tudor Ambarus
2024-06-06 13:59 ` Michael Walle
2024-06-06 14:52 ` Tudor Ambarus
2024-06-06 15:06 ` Michael Walle
2024-06-06 17:20 ` Esben Haabendal
2024-06-07 9:22 ` Tudor Ambarus
2024-06-07 13:30 ` Esben Haabendal
2024-06-12 8:51 ` Michael Walle [this message]
2024-06-06 17:20 ` Esben Haabendal
2024-07-10 18:42 ` Esben Haabendal
2024-07-11 9:02 ` Michael Walle
2024-07-11 11:55 ` Esben Haabendal
2024-06-06 17:13 ` Esben Haabendal
2024-06-03 13:09 ` [PATCH v2 2/2] mtd: spi-nor: macronix: enable quad/dual speed for mx25l3205d chips Esben Haabendal
2024-06-06 13:33 ` Tudor Ambarus
2024-06-06 17:23 ` Esben Haabendal
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=D1XWS6SSXALZ.3NKR71449UYAO@kernel.org \
--to=mwalle@kernel.org \
--cc=esben@geanix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=rasmus.villemoes@prevas.dk \
--cc=richard@nod.at \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.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).