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 16/19] mtd: spi-nor: Add steps for testing locking support
Date: Tue, 18 Nov 2025 13:24:02 +0100 [thread overview]
Message-ID: <DEBTGMKJKVAC.OT51M7UDN4IV@kernel.org> (raw)
In-Reply-To: <20251114-winbond-v6-18-rc1-spi-nor-swp-v1-16-487bc7129931@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 7041 bytes --]
On Fri Nov 14, 2025 at 6:53 PM CET, Miquel Raynal wrote:
> As recently raised on the mailing list, it may be useful to propose a
> list of steps to go through in order to proove the devices have been
> described correctly, especially since all the block protection
> information is not stored in any kind of table and is instead filled
> manually by developpers.
>
> Use the debugfs output to ease the comparison between expectations and
> reality.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> Documentation/driver-api/mtd/spi-nor.rst | 118 +++++++++++++++++++++++++++++++
> 1 file changed, 118 insertions(+)
>
> diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
> index 148fa4288760b6ba47d530ed72c5ef81397d598f..d56ff5c42a98af23a65097c9b77cd20ef2504a49 100644
> --- a/Documentation/driver-api/mtd/spi-nor.rst
> +++ b/Documentation/driver-api/mtd/spi-nor.rst
> @@ -203,3 +203,121 @@ section, after the ``---`` marker.
> mtd.writesize = 1
> mtd.oobsize = 0
> regions = 0
> +
> +5) If your flash supports locking, also follow the following test
> + procedure to make sure it correctly behaves. These tests must be
> + conducted with #WP high (no hardware protection) or the `no-wp`
> + property in the DT node.
Or? If WPn is low, the no-wp property doesn't matter. It's hardware
write protected. Also there is that corner case, where you can
actually fully lock your flash: WPn hard tied to low. Be aware, that
you can enable locking even if WPn is tied low. That has the use
case to initially program the flash and then lock it forever. So we
might add a warning note, that WPn should somehow be controllable
(or be sure that is tied high) before conducting the locking tests.
> +
> + Test full chip locking and make sure expectations, the MEMISLOCKED
> + ioctl output, the debugfs output and experimental results are all
> + aligned::
> +
> + root@1:~# alias show_sectors='grep -A4 "locked sectors" /sys/kernel/debug/spi-nor/spi0.0/params'
> + root@1:~# flash_lock -u /dev/mtd0
> + root@1:~# flash_lock -i /dev/mtd0
> + Device: /dev/mtd0
> + Start: 0
> + Len: 0x4000000
> + Lock status: unlocked
> + Return code: 0
> + root@1:~# mtd_debug erase /dev/mtd0 0 2097152
> + Erased 2097152 bytes from address 0x00000000 in flash
> + root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test
> + Copied 2097152 bytes from spi_test to address 0x00000000 in flash
> + root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
> + Copied 2097152 bytes from address 0x00000000 in flash to spi_read
> + root@1:~# sha256sum spi*
> + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
> + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
> + root@1:~# show_sectors
> + software locked sectors
> + region (in hex) | status | #blocks
> + ------------------+----------+--------
> + 00000000-03ffffff | unlocked | 1024
> +
> + root@1:~# flash_lock -l /dev/mtd0
> + root@1:~# flash_lock -i /dev/mtd0
> + Device: /dev/mtd0
> + Start: 0
> + Len: 0x4000000
> + Lock status: locked
> + Return code: 1
> + root@1:~# mtd_debug erase /dev/mtd0 0 2097152
> + Erased 2097152 bytes from address 0x00000000 in flash
> + root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
> + Copied 2097152 bytes from address 0x00000000 in flash to spi_read
> + root@1:~# sha256sum spi*
> + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
> + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
> + root@1:~# dd if=/dev/urandom of=./spi_test2 bs=1M count=2
> + 2+0 records in
> + 2+0 records out
> + root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test2
> + Copied 2097152 bytes from spi_test to address 0x00000000 in flash
> + root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read2
> + Copied 2097152 bytes from address 0x00000000 in flash to spi_read
> + root@1:~# sha256sum spi*
> + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
> + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read2
> + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
> + bea9334df51c620440f86751cba0799214a016329f1736f9456d40cf40efdc88 spi_test2
> + root@1:~# show_sectors
> + software locked sectors
> + region (in hex) | status | #blocks
> + ------------------+----------+--------
> + 00000000-03ffffff | locked | 1024
> +
> + Once we trust the debugfs output we can use it to test various
> + situations. Check top locking/unlocking (end of the device)::
> +
> + root@1:~# bs=$(cat /sys/class/mtd/mtd0/erasesize)
> + root@1:~# size=$(cat /sys/class/mtd/mtd0/size)
> +
> + root@1:~# flash_lock -u /dev/mtd0
> + root@1:~# flash_lock -l /dev/mtd0 $(($size - (2 * $bs))) 2 # last two
> + root@1:~# show_sectors
> + software locked sectors
> + region (in hex) | status | #blocks
> + ------------------+----------+--------
> + 00000000-03fdffff | unlocked | 1022
> + 03fe0000-03ffffff | locked | 2
> + root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # last one
huh? shouldn't that be 1 * $bs?
-michael
> + root@1:~# show_sectors
> + software locked sectors
> + region (in hex) | status | #blocks
> + ------------------+----------+--------
> + 00000000-03feffff | unlocked | 1023
> + 03ff0000-03ffffff | locked | 1
> +
> + If the flash features 4 block protection bits (BP), we can protect
> + more than 4MB (typically 128 64kiB-blocks or more), with a finer
> + grain than locking the entire device::
> +
> + root@1:~# flash_lock -u /dev/mtd0
> + root@1:~# flash_lock -l /dev/mtd0 $(($size - (2**7 * $bs))) $((2**7))
> + root@1:~# show_sectors
> + software locked sectors
> + region (in hex) | status | #blocks
> + ------------------+----------+--------
> + 00000000-037fffff | unlocked | 896
> + 03800000-03ffffff | locked | 128
> +
> + If the flash features a Top/Bottom (TB) bit, we can protect the
> + beginning of the flash::
> +
> + root@1:~# flash_lock -u /dev/mtd0
> + root@1:~# flash_lock -l /dev/mtd0 0 2 # first two
> + root@1:~# show_sectors
> + software locked sectors
> + region (in hex) | status | #blocks
> + ------------------+----------+--------
> + 00000000-0001ffff | locked | 2
> + 00020000-03ffffff | unlocked | 1022
> + root@1:~# flash_lock -u /dev/mtd0 $bs 1 # first one
> + root@1:~# show_sectors
> + software locked sectors
> + region (in hex) | status | #blocks
> + ------------------+----------+--------
> + 00000000-0000ffff | locked | 1
> + 00010000-03ffffff | unlocked | 1023
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
next prev parent reply other threads:[~2025-11-18 12:24 UTC|newest]
Thread overview: 38+ 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 ` [PATCH 01/19] mtd: spi-nor: debugfs: Fix the flags list Miquel Raynal
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-18 9:17 ` Michael Walle
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-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-18 9:23 ` Michael Walle
2025-11-14 17:53 ` [PATCH 05/19] mtd: spi-nor: debugfs: Enhance output Miquel Raynal
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-18 9:53 ` Michael Walle
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-18 9:55 ` Michael Walle
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 ` [PATCH 09/19] mtd: spi-nor: swp: Create a helper that writes SR, CR and checks Miquel Raynal
2025-11-14 17:53 ` [PATCH 10/19] mtd: spi-nor: swp: Rename a mask 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 ` [PATCH 12/19] mtd: spi-nor: swp: Create helpers for building the SR register 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 ` [PATCH 14/19] mtd: spi-nor: swp: Cosmetic changes Miquel Raynal
2025-11-14 17:53 ` [PATCH 15/19] mtd: spi-nor: debugfs: Add locking support Miquel Raynal
2025-11-18 12:46 ` Michael Walle
2025-11-19 9:49 ` Miquel Raynal
2025-11-19 10:50 ` Michael Walle
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-18 12:24 ` Michael Walle [this message]
2025-11-19 9:40 ` Miquel Raynal
2025-11-19 10:27 ` Michael Walle
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 ` [PATCH 18/19] mtd: spi-nor: Add steps for testing locking with CMP Miquel Raynal
2025-11-14 17:53 ` [PATCH 19/19] mtd: spi-nor: winbond: Add CMP locking support 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=DEBTGMKJKVAC.OT51M7UDN4IV@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 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).