From: sashiko-bot@kernel.org
To: "Miquel Raynal" <miquel.raynal@bootlin.com>,
"Michael Walle" <mwalle@kernel.org>,
"Pratyush Yadav" <pratyush@kernel.org>,
"Takahiro Kuwano" <takahiro.kuwano@infineon.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>
Cc: "Jon Hunter" <jonathanh@nvidia.com>,
linux-kernel@vger.kernel.org, "Steam Lin" <STLin2@winbond.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH] mtd: spi-nor: Fix quad-enable for flashes with QER bit in SR1
Date: Fri, 11 Sep 2026 09:12:48 +0000 [thread overview]
Message-ID: <20260911091249.383221F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260911-perso-fix-spi-nor-qe-mxic-v1-1-fd6d91416a2a@bootlin.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Unintended Register Corruption for Flashes with `qe_mask[0]` and an Active SR2.
Pre-existing issues:
- [High] spi_nor_write_sr1_and_sr2_and_check() still fails unconditionally for flashes without SR2 if the QE bit needs to be set.
--
commit f2fd5923d5c3121a4c7513816b2b4ce3fb7e3a48
Author: Miquel Raynal <miquel.raynal@bootlin.com>
mtd: spi-nor: Fix quad-enable for flashes with QER bit in SR1
The patch modifies spi_nor_generic_quad_enable to only read SR1 when
qe_mask[0] is set. This aims to fix probe failures on flashes lacking
an SR2.
Closes: https://lore.kernel.org/linux-mtd/178876719232.3543902.14451625037676421254.b4-ty@b4/T/#m5bc4ba6776436f2870ced0eb5789d229037ad840
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index e2b6efafdd8d0..ac909dfb9657c 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -985,7 +985,10 @@ static int spi_nor_generic_quad_enable(struct spi_nor *nor)
> if (!qe_mask[0] && !qe_mask[1])
> return 0;
>
> - ret = spi_nor_read_sr1_and_sr2(nor, sr);
> + if (qe_mask[0])
> + ret = spi_nor_read_sr1(nor, sr);
[Severity: High]
If qe_mask[0] is set and the flash has an active SR2, does this leave sr[1]
unpopulated as 0x00 without ensuring the flash actually lacks a two-byte
write opcode?
Later in this function, if the QE bit is not already set, it calls:
return spi_nor_write_sr1_and_sr2_and_check(nor, sr);
This will invoke the helper which executes the two-byte write_sr1_and_sr2
opcode if set, writing the unpopulated sr[1] (0x00) to the flash's SR2/CR.
Can this corrupt the flash state and fail the validation check if the second
byte reads back as non-zero?
> + else
> + ret = spi_nor_read_sr1_and_sr2(nor, sr);
> if (ret)
> return ret;
>
[Severity: High]
This is a pre-existing issue, but does this still fail unconditionally for
flashes without SR2 if the QE bit needs to be set?
If the QE bit is not already set, spi_nor_generic_quad_enable() proceeds to
call spi_nor_write_sr1_and_sr2_and_check(), which reads both registers for
verification:
drivers/mtd/spi-nor/core.c:spi_nor_write_sr1_and_sr2_and_check() {
...
ret = spi_nor_read_sr1_and_sr2(nor, tmp);
if (ret)
return ret;
...
}
Because read_sr2 is 0 for flashes lacking SR2, spi_nor_read_sr2() returns
-EINVAL. Doesn't this mean the generic helper still fails with -EINVAL during
verification?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-perso-fix-spi-nor-qe-mxic-v1-1-fd6d91416a2a@bootlin.com?part=1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-09-11 9:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 8:55 [PATCH] mtd: spi-nor: Fix quad-enable for flashes with QER bit in SR1 Miquel Raynal
2026-09-11 9:04 ` Michael Walle
2026-09-11 9:19 ` Miquel Raynal
2026-09-11 9:30 ` Michael Walle
2026-09-11 9:34 ` Miquel Raynal
2026-09-11 10:00 ` Michael Walle
2026-09-11 10:43 ` Miquel Raynal
2026-09-11 9:12 ` sashiko-bot [this message]
2026-09-11 10:33 ` Jon Hunter
2026-09-11 12:06 ` Michael Walle
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=20260911091249.383221F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=STLin2@winbond.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=sashiko-reviews@lists.linux.dev \
--cc=takahiro.kuwano@infineon.com \
--cc=thomas.petazzoni@bootlin.com \
--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 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.