From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Sean Anderson <sean.anderson@linux.dev>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
linux-mtd@lists.infradead.org,
Richard Weinberger <richard@nod.at>,
linux-kernel@vger.kernel.org,
Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [PATCH] mtd: spi-nor: Enable locking for n25q00a
Date: Fri, 14 Nov 2025 18:55:59 +0100 [thread overview]
Message-ID: <87ldk8fqhc.fsf@bootlin.com> (raw)
In-Reply-To: <3f415ff1-834e-4544-a093-dcb4fd25d5c9@linux.dev> (Sean Anderson's message of "Thu, 13 Nov 2025 10:32:05 -0500")
Hello,
>> I am also working on locking these days, have you already started
>> writing extra SPI NOR Documentation/process based on this thread?
>
> I haven't started writing anything.
>
>> I am also trying to clarify what is expected and what the API somehow
>> does, as it was not fully clear for me at first sight.
>
> I agree, as you could probably have figured out.
>
>>> # flash_lock -u /dev/mtd/by-name/spi0.1
>>> # test spi0.1 64
>>> 83a8dc6125ec9672d18f7f18f92e16f867354dbe8e2f3b0aca52b9d0ad7d8ffe spi0.1
>>> 83a8dc6125ec9672d18f7f18f92e16f867354dbe8e2f3b0aca52b9d0ad7d8ffe -
>>> # flash_lock -l /dev/mtd/by-name/spi0.1 $((1024 * 64 * 1024)) 1024
>>> # flash_lock -i /dev/mtd/by-name/spi0.1
>>> Device: /dev/mtd/by-name/spi0.1
>>> Start: 0
>>> Len: 0x8000000
>>> Lock status: unlocked <<<< Wrong!
>>
>> This isn't wrong, even though at a first glance the output is
>> misleading. The API apparently does not gives you all the
>> locked/unlocked sectors, it is way more basic than that: it tells you
>> whether the full range you asked for is indeed locked.
>
> Yeah, I figured that out eventually.
>
> Actually, the most surprising thing to me is that the lock/unlock APIs
> are not incremental. That is, if I have a flash of 8 seconds, and
> sectors 0-3 are locked and I lock sectors 0-1, it will say "well,
> sectors 2-3 should be unlocked now, but we're not allowed to unlock
> during a lock operation" and fail to lock. I would have expected it to
> say "sectors 0-1 are already locked so we don't need to do anything".
> The only way to go from sectors 0-3 to 0-1 being locked is to issue an
> *unlock* on sectors 2-7.
>
> Conversely, if what you wanted to do was ensure sectors 2-3 were
> unlocked, you can't do the naive thing and unlock sectors 2-3, since
> that will try to lock sectors 0-1 and 4-7, the latter being disallowed
> in an unlock operation. So you actually have to unlock sectors 2-7.
>
> And knowing what to do is complicated by ISLOCKED only returning a
> boolean instead of just telling userspace what sectors are locked (which
> must be a small finite set of ranges (usually one) on all flashes I'm
> familiar with).
I've tried to address most of this, see:
Link: https://lore.kernel.org/linux-mtd/20251114-winbond-v6-18-rc1-spi-nor-swp-v1-0-487bc7129931@bootlin.com/T/#mbae8b874181eb0401b30142f423b73b6389a0c54
Kind regards,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Sean Anderson <sean.anderson@linux.dev>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
linux-mtd@lists.infradead.org,
Richard Weinberger <richard@nod.at>,
linux-kernel@vger.kernel.org,
Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [PATCH] mtd: spi-nor: Enable locking for n25q00a
Date: Fri, 14 Nov 2025 18:55:59 +0100 [thread overview]
Message-ID: <87ldk8fqhc.fsf@bootlin.com> (raw)
In-Reply-To: <3f415ff1-834e-4544-a093-dcb4fd25d5c9@linux.dev> (Sean Anderson's message of "Thu, 13 Nov 2025 10:32:05 -0500")
Hello,
>> I am also working on locking these days, have you already started
>> writing extra SPI NOR Documentation/process based on this thread?
>
> I haven't started writing anything.
>
>> I am also trying to clarify what is expected and what the API somehow
>> does, as it was not fully clear for me at first sight.
>
> I agree, as you could probably have figured out.
>
>>> # flash_lock -u /dev/mtd/by-name/spi0.1
>>> # test spi0.1 64
>>> 83a8dc6125ec9672d18f7f18f92e16f867354dbe8e2f3b0aca52b9d0ad7d8ffe spi0.1
>>> 83a8dc6125ec9672d18f7f18f92e16f867354dbe8e2f3b0aca52b9d0ad7d8ffe -
>>> # flash_lock -l /dev/mtd/by-name/spi0.1 $((1024 * 64 * 1024)) 1024
>>> # flash_lock -i /dev/mtd/by-name/spi0.1
>>> Device: /dev/mtd/by-name/spi0.1
>>> Start: 0
>>> Len: 0x8000000
>>> Lock status: unlocked <<<< Wrong!
>>
>> This isn't wrong, even though at a first glance the output is
>> misleading. The API apparently does not gives you all the
>> locked/unlocked sectors, it is way more basic than that: it tells you
>> whether the full range you asked for is indeed locked.
>
> Yeah, I figured that out eventually.
>
> Actually, the most surprising thing to me is that the lock/unlock APIs
> are not incremental. That is, if I have a flash of 8 seconds, and
> sectors 0-3 are locked and I lock sectors 0-1, it will say "well,
> sectors 2-3 should be unlocked now, but we're not allowed to unlock
> during a lock operation" and fail to lock. I would have expected it to
> say "sectors 0-1 are already locked so we don't need to do anything".
> The only way to go from sectors 0-3 to 0-1 being locked is to issue an
> *unlock* on sectors 2-7.
>
> Conversely, if what you wanted to do was ensure sectors 2-3 were
> unlocked, you can't do the naive thing and unlock sectors 2-3, since
> that will try to lock sectors 0-1 and 4-7, the latter being disallowed
> in an unlock operation. So you actually have to unlock sectors 2-7.
>
> And knowing what to do is complicated by ISLOCKED only returning a
> boolean instead of just telling userspace what sectors are locked (which
> must be a small finite set of ranges (usually one) on all flashes I'm
> familiar with).
I've tried to address most of this, see:
Link: https://lore.kernel.org/linux-mtd/20251114-winbond-v6-18-rc1-spi-nor-swp-v1-0-487bc7129931@bootlin.com/T/#mbae8b874181eb0401b30142f423b73b6389a0c54
Kind regards,
Miquèl
next prev parent reply other threads:[~2025-11-14 17:56 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 22:34 [PATCH] mtd: spi-nor: Enable locking for n25q00a Sean Anderson
2025-10-06 22:34 ` Sean Anderson
2025-10-06 22:38 ` Sean Anderson
2025-10-06 22:38 ` Sean Anderson
2025-10-08 5:05 ` Tudor Ambarus
2025-10-08 5:05 ` Tudor Ambarus
2025-10-08 12:38 ` Pratyush Yadav
2025-10-08 12:38 ` Pratyush Yadav
2025-10-07 13:15 ` Pratyush Yadav
2025-10-07 13:15 ` Pratyush Yadav
2025-10-07 14:20 ` Sean Anderson
2025-10-07 14:20 ` Sean Anderson
2025-10-08 12:30 ` Pratyush Yadav
2025-10-08 12:30 ` Pratyush Yadav
2025-10-08 12:40 ` Pratyush Yadav
2025-10-08 12:40 ` Pratyush Yadav
2025-10-09 22:27 ` Sean Anderson
2025-10-09 22:27 ` Sean Anderson
2025-10-09 23:07 ` Pratyush Yadav
2025-10-09 23:07 ` Pratyush Yadav
2025-10-10 15:45 ` Sean Anderson
2025-10-10 15:45 ` Sean Anderson
2025-10-13 7:30 ` Tudor Ambarus
2025-10-13 7:30 ` Tudor Ambarus
2025-10-14 18:25 ` Sean Anderson
2025-10-14 18:25 ` Sean Anderson
2025-11-10 7:08 ` Tudor Ambarus
2025-11-10 7:08 ` Tudor Ambarus
2025-11-10 10:16 ` Pratyush Yadav
2025-11-10 10:16 ` Pratyush Yadav
2025-11-10 16:36 ` Sean Anderson
2025-11-10 16:36 ` Sean Anderson
2025-11-11 6:07 ` Tudor Ambarus
2025-11-11 6:07 ` Tudor Ambarus
2025-11-12 13:10 ` Miquel Raynal
2025-11-12 13:10 ` Miquel Raynal
2025-11-12 13:20 ` Miquel Raynal
2025-11-12 13:20 ` Miquel Raynal
2025-11-12 13:34 ` Michael Walle
2025-11-12 13:34 ` Michael Walle
2025-11-13 15:32 ` Sean Anderson
2025-11-13 15:32 ` Sean Anderson
2025-11-14 17:55 ` Miquel Raynal [this message]
2025-11-14 17:55 ` 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=87ldk8fqhc.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=sean.anderson@linux.dev \
--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.