All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Michael Walle" <mwalle@kernel.org>
Cc: "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>,
	"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: Wed, 19 Nov 2025 18:35:38 +0100	[thread overview]
Message-ID: <878qg2apsl.fsf@bootlin.com> (raw)
In-Reply-To: <DECLLWEB1UTF.JO173TKNZ28M@kernel.org> (Michael Walle's message of "Wed, 19 Nov 2025 11:27:27 +0100")

>> 5) If your flash supports locking, please got through the following test
>>    procedure to make sure it correctly behaves.
>>
>>    Warning: These tests may hard lock your device! Make sure:
>>    - The device is not hard locked already (#WP strapped to low and
>>      SR_SRWD bit set)
>>    - If you have a #WP pin, you may want to set `no-wp` in your DT for
>>      the time of the test, to only make use of software protection.
>
> Yes that is much better. BTW, I've never seen "#signal" but only
> SIG#, nSIG, SIGn or /SIG, maybe I haven't paid too much attention.

Ah, right. I'm fine either ways. I'll look for occurrences and use one
of your suggestions.

>> Please amend this text if you still think it is missing his goal.
>
> What about
>
>     - If you have a WPn pin, you may want to set `no-wp` in your DT for
>       the time of the test, to only make use of software protection.
>       Otherwise, clearing the locking state depends on the WPn
>       signal and if it is tied to low, the flash will be permanently
>       locked.

Yep, I'll use that.

>>>> +    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?
>>
>> I don't think so:
>> - first we lock the last two blocks (offset: size - 2 blocks, length: 2
>>   blocks)
>> - then we unlock the penultimate block so that only the last block
>>   remains locked (offset: size - 2 blocks, length 1).
>
> Yes you're correct. I've read the -u for a -l (and somehow assumed
> a complete unlock in between).

You cannot imagine how many times this happened to me while
writing/testing/documenting all this :-)

Thanks,
Miquèl

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Michael Walle" <mwalle@kernel.org>
Cc: "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>,
	"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: Wed, 19 Nov 2025 18:35:38 +0100	[thread overview]
Message-ID: <878qg2apsl.fsf@bootlin.com> (raw)
In-Reply-To: <DECLLWEB1UTF.JO173TKNZ28M@kernel.org> (Michael Walle's message of "Wed, 19 Nov 2025 11:27:27 +0100")

>> 5) If your flash supports locking, please got through the following test
>>    procedure to make sure it correctly behaves.
>>
>>    Warning: These tests may hard lock your device! Make sure:
>>    - The device is not hard locked already (#WP strapped to low and
>>      SR_SRWD bit set)
>>    - If you have a #WP pin, you may want to set `no-wp` in your DT for
>>      the time of the test, to only make use of software protection.
>
> Yes that is much better. BTW, I've never seen "#signal" but only
> SIG#, nSIG, SIGn or /SIG, maybe I haven't paid too much attention.

Ah, right. I'm fine either ways. I'll look for occurrences and use one
of your suggestions.

>> Please amend this text if you still think it is missing his goal.
>
> What about
>
>     - If you have a WPn pin, you may want to set `no-wp` in your DT for
>       the time of the test, to only make use of software protection.
>       Otherwise, clearing the locking state depends on the WPn
>       signal and if it is tied to low, the flash will be permanently
>       locked.

Yep, I'll use that.

>>>> +    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?
>>
>> I don't think so:
>> - first we lock the last two blocks (offset: size - 2 blocks, length: 2
>>   blocks)
>> - then we unlock the penultimate block so that only the last block
>>   remains locked (offset: size - 2 blocks, length 1).
>
> Yes you're correct. I've read the -u for a -l (and somehow assumed
> a complete unlock in between).

You cannot imagine how many times this happened to me while
writing/testing/documenting all this :-)

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2025-11-19 17:35 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
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 [this message]
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=878qg2apsl.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --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=mwalle@kernel.org \
    --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.