Message-ID: <87tsyqcqcl.fsf@bootlin.com>
Date: Wed, 19 Nov 2025 10:40:42 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: "Michael Walle" <mwalle@...nel.org>
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 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.

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.

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

Please amend this text if you still think it is missing his goal.

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

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