Message-Id: <DECLLWEB1UTF.JO173TKNZ28M@kernel.org>
Date: Wed, 19 Nov 2025 11:27:27 +0100
From: "Michael Walle" <mwalle@...nel.org>
To: "Miquel Raynal" <miquel.raynal@...tlin.com>
Cc: "Tudor Ambarus" <tudor.ambarus@...aro.org>, "Pratyush Yadav"
 <pratyush@...nel.org>, "Richard Weinberger" <richard@....at>, "Vignesh
 Raghavendra" <vigneshr@...com>, "Jonathan Corbet" <corbet@....net>, "Sean
 Anderson" <sean.anderson@...ux.dev>, "Thomas Petazzoni"
 <thomas.petazzoni@...tlin.com>, "Steam Lin" <STLin2@...bond.com>,
 <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
 <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 16/19] mtd: spi-nor: Add steps for testing locking
 support

On Wed Nov 19, 2025 at 10:40 AM CET, Miquel Raynal wrote:
> On 18/11/2025 at 13:24:02 +01, "Michael Walle" <mwalle@...nel.org> wrote:
>
>> 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@...tlin.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.
>
> This is only correct if the SRP bit is set. If the SRP bit is unset, #WP
> low still has no impact. And this is why setting the no-wp property
> matters, because otherwise the SR_SRWD bit gets set at the first locking
> command.

Yes, but only if it's not write-protected before. The text read as
if you could ignore the hardware write protection. More below.

> I disliked this behaviour as I actually got almost locked with
> a non drivable #WP pin and had to play with pinctrl in order to force it
> high and allow me to overwrite the SR_SRWD bit back.

That no-wp property was recently introduced because of faulty
hardware. Before that, locking was always the "real" hardware
write-protection.

>> 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.
>
> Yes, that is the situation I met, it is not documented anywhere except
> the code.
>
> My intent with this paragraph was to hint people not to conduct these
> tests under certain situations, but we can definitely improve that. What
> about:
>
> 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.

> 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.


>
>>> +    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).

> I we were doing flash_lock -u <mtd> $(($size - (1 * $bs))) 1, we would
> be asking to unlock the very last block and keep only the penultimate
> block locked, which would not be supported.
>
> Thanks,
> Miquèl

Powered by blists - more mailing lists