From: "Michael Walle" <mwalle@kernel.org>
To: "Miquel Raynal" <miquel.raynal@bootlin.com>,
"Tudor Ambarus" <tudor.ambarus@linaro.org>,
"Pratyush Yadav" <pratyush@kernel.org>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Jonathan Corbet" <corbet@lwn.net>
Cc: "Sean Anderson" <sean.anderson@linux.dev>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Steam Lin" <STLin2@winbond.com>, <linux-mtd@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>
Subject: Re: [PATCH 02/19] mtd: spi-nor: swp: Improve locking user experience
Date: Tue, 18 Nov 2025 10:17:55 +0100 [thread overview]
Message-ID: <DEBPI49KKW00.3MSWMX9HQL7JZ@kernel.org> (raw)
In-Reply-To: <20251114-winbond-v6-18-rc1-spi-nor-swp-v1-2-487bc7129931@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]
On Fri Nov 14, 2025 at 6:53 PM CET, Miquel Raynal wrote:
> In the case of a single block being locked, if the user want to fully
> unlock the device it has two possibilities:
> - either it asks to unlock the entire device, and this works;
> - or it asks to unlock just the blocks that are currently locked, which
> fails.
>
> It fails because the conditions "can_be_top" and "can_be_bottom" are
> true. Indeed, in this case, we unlock everything, to the TB bit does not
> matter. However in the current implementation, use_top would be true (as
> this is the favourite option) and lock_len, which in practice should be
> reduced down to 0, is set to "nor->params->size - (ofs + len)" which is
> a positive number. This is wrong.
This only happens if you try to unlock the first sector, correct? If
my maths are correct, trying it on the last sector, lock_len should
be 0, i.e in that case "ofs + len == size".
If it's the first sector (or sectors), lock_len will end up with
"size - N * 64k", which is clearly wrong.
> An easy way is to simply add an extra condition. In the unlock() path,
> if we can achieve the results from both sides, it means we unlock
> everything and lock_len must simply be 0.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> For me, this result was clearly unexpected, but I am not sure this
> qualifies as a fix.
That's definetly a bug, esp. because it will lock an entire
unrelated region. And it seems to go back all the to commit
3dd8012a8eeb "mtd: spi-nor: add TB (Top/Bottom) protect support").
> ---
> drivers/mtd/spi-nor/swp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
> index 9b07f83aeac76dce2109f90dfa1534c9bd93330d..9bc5a356444665ad8824e9e12d679fd551b3e67d 100644
> --- a/drivers/mtd/spi-nor/swp.c
> +++ b/drivers/mtd/spi-nor/swp.c
> @@ -281,7 +281,9 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
> use_top = can_be_top;
>
> /* lock_len: length of region that should remain locked */
> - if (use_top)
> + if (can_be_top && can_be_bottom)
> + lock_len = 0;
Could you please add a comment stating that if both are true, it
means that both adjacent regions are unlocked and thus the entire
flash will be unlocked.
-michael
> + else if (use_top)
> lock_len = nor->params->size - (ofs + len);
> else
> lock_len = ofs;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Michael Walle" <mwalle@kernel.org>
To: "Miquel Raynal" <miquel.raynal@bootlin.com>,
"Tudor Ambarus" <tudor.ambarus@linaro.org>,
"Pratyush Yadav" <pratyush@kernel.org>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Jonathan Corbet" <corbet@lwn.net>
Cc: "Sean Anderson" <sean.anderson@linux.dev>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Steam Lin" <STLin2@winbond.com>, <linux-mtd@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>
Subject: Re: [PATCH 02/19] mtd: spi-nor: swp: Improve locking user experience
Date: Tue, 18 Nov 2025 10:17:55 +0100 [thread overview]
Message-ID: <DEBPI49KKW00.3MSWMX9HQL7JZ@kernel.org> (raw)
In-Reply-To: <20251114-winbond-v6-18-rc1-spi-nor-swp-v1-2-487bc7129931@bootlin.com>
[-- Attachment #1.1: Type: text/plain, Size: 2472 bytes --]
On Fri Nov 14, 2025 at 6:53 PM CET, Miquel Raynal wrote:
> In the case of a single block being locked, if the user want to fully
> unlock the device it has two possibilities:
> - either it asks to unlock the entire device, and this works;
> - or it asks to unlock just the blocks that are currently locked, which
> fails.
>
> It fails because the conditions "can_be_top" and "can_be_bottom" are
> true. Indeed, in this case, we unlock everything, to the TB bit does not
> matter. However in the current implementation, use_top would be true (as
> this is the favourite option) and lock_len, which in practice should be
> reduced down to 0, is set to "nor->params->size - (ofs + len)" which is
> a positive number. This is wrong.
This only happens if you try to unlock the first sector, correct? If
my maths are correct, trying it on the last sector, lock_len should
be 0, i.e in that case "ofs + len == size".
If it's the first sector (or sectors), lock_len will end up with
"size - N * 64k", which is clearly wrong.
> An easy way is to simply add an extra condition. In the unlock() path,
> if we can achieve the results from both sides, it means we unlock
> everything and lock_len must simply be 0.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> For me, this result was clearly unexpected, but I am not sure this
> qualifies as a fix.
That's definetly a bug, esp. because it will lock an entire
unrelated region. And it seems to go back all the to commit
3dd8012a8eeb "mtd: spi-nor: add TB (Top/Bottom) protect support").
> ---
> drivers/mtd/spi-nor/swp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
> index 9b07f83aeac76dce2109f90dfa1534c9bd93330d..9bc5a356444665ad8824e9e12d679fd551b3e67d 100644
> --- a/drivers/mtd/spi-nor/swp.c
> +++ b/drivers/mtd/spi-nor/swp.c
> @@ -281,7 +281,9 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
> use_top = can_be_top;
>
> /* lock_len: length of region that should remain locked */
> - if (use_top)
> + if (can_be_top && can_be_bottom)
> + lock_len = 0;
Could you please add a comment stating that if both are true, it
means that both adjacent regions are unlocked and thus the entire
flash will be unlocked.
-michael
> + else if (use_top)
> lock_len = nor->params->size - (ofs + len);
> else
> lock_len = ofs;
[-- 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:[~2025-11-18 9:18 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 17:53 [PATCH 00/19] mtd: spi-nor: Enhance software protection Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 01/19] mtd: spi-nor: debugfs: Fix the flags list Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 7:43 ` Michael Walle
2025-11-18 7:43 ` Michael Walle
2025-11-14 17:53 ` [PATCH 02/19] mtd: spi-nor: swp: Improve locking user experience Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 9:17 ` Michael Walle [this message]
2025-11-18 9:17 ` Michael Walle
2025-11-19 9:13 ` Miquel Raynal
2025-11-19 9:13 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 03/19] mtd: spi-nor: Improve opcodes documentation Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 9:22 ` Michael Walle
2025-11-18 9:22 ` Michael Walle
2025-11-14 17:53 ` [PATCH 04/19] mtd: spi-nor: debugfs: Align variable access with the rest of the file Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 9:23 ` Michael Walle
2025-11-18 9:23 ` Michael Walle
2025-11-14 17:53 ` [PATCH 05/19] mtd: spi-nor: debugfs: Enhance output Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 9:24 ` Michael Walle
2025-11-18 9:24 ` Michael Walle
2025-11-14 17:53 ` [PATCH 06/19] mtd: spi-nor: swp: Explain the MEMLOCK ioctl implementation behaviour Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 9:53 ` Michael Walle
2025-11-18 9:53 ` Michael Walle
2025-11-19 9:18 ` Miquel Raynal
2025-11-19 9:18 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 07/19] mtd: spi-nor: swp: Clarify a comment Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 9:55 ` Michael Walle
2025-11-18 9:55 ` Michael Walle
2025-11-19 9:19 ` Miquel Raynal
2025-11-19 9:19 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 08/19] mtd: spi-nor: swp: Use a pointer for SR instead of a single byte Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 09/19] mtd: spi-nor: swp: Create a helper that writes SR, CR and checks Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 10/19] mtd: spi-nor: swp: Rename a mask Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 11/19] mtd: spi-nor: swp: Create a TB intermediate variable Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 12/19] mtd: spi-nor: swp: Create helpers for building the SR register Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 13/19] mtd: spi-nor: swp: Simplify checking the locked/unlocked range Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 14/19] mtd: spi-nor: swp: Cosmetic changes Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 15/19] mtd: spi-nor: debugfs: Add locking support Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 12:46 ` Michael Walle
2025-11-18 12:46 ` Michael Walle
2025-11-19 9:49 ` Miquel Raynal
2025-11-19 9:49 ` Miquel Raynal
2025-11-19 10:50 ` Michael Walle
2025-11-19 10:50 ` Michael Walle
2025-11-19 17:43 ` Miquel Raynal
2025-11-19 17:43 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 16/19] mtd: spi-nor: Add steps for testing " Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-18 12:24 ` Michael Walle
2025-11-18 12:24 ` Michael Walle
2025-11-19 9:40 ` Miquel Raynal
2025-11-19 9:40 ` Miquel Raynal
2025-11-19 10:27 ` Michael Walle
2025-11-19 10:27 ` Michael Walle
2025-11-19 17:35 ` Miquel Raynal
2025-11-19 17:35 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 17/19] mtd: spi-nor: swp: Add support for the complement feature Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 18/19] mtd: spi-nor: Add steps for testing locking with CMP Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
2025-11-14 17:53 ` [PATCH 19/19] mtd: spi-nor: winbond: Add CMP locking support Miquel Raynal
2025-11-14 17:53 ` Miquel Raynal
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=DEBPI49KKW00.3MSWMX9HQL7JZ@kernel.org \
--to=mwalle@kernel.org \
--cc=STLin2@winbond.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=sean.anderson@linux.dev \
--cc=thomas.petazzoni@bootlin.com \
--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 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.