Re: [PATCH v3] mtd: spi-nor: take the flash lock around spi_nor_restore()

[Itai Handler]

On Fri, Sep 18, 2026 at 12:34 PM Michael Walle <mwalle@xxxxxxxxxx> wrote:
>
> On Tue Sep 15, 2026 at 1:52 PM CEST, sashiko-bot wrote:
> > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > - [High] mtd: spi-nor: skipped flash restore on fatal signal breaks boot
> > - [High] mtd: spi-nor: shutdown hang due to ongoing erase operation
>
> Does Sashiko have some valid points here?

Here is my perspective on the two points raised by Sashiko:

Signal Interruption during Lock Acquisition (Issue 1):
Sashiko's point is valid, though this scenario only applies to RWW chips
where spi_nor_prep_and_lock() uses wait_event_killable(). The window
for this to occur is quite narrow (e.g., sending SIGKILL to rmmod while
an operation is in progress).
If lock acquisition is interrupted, calling spi_nor_restore() without
the lock as a fallback risks having the command silently ignored by
a busy flash. However, it may still be worth attempting as a
best-effort fallback alongside a kernel warning log to notify the user.

Erase Duration during Shutdown (Issue 2):
Waiting for active operations to complete before restoring 3-byte
mode is intentional. Interrupting an ongoing erase or write cycle
risks corrupting the flash or leaving the chip in an undefined state.
Allowing active operations to finish before teardown is standard
behavior to guarantee data integrity.

If this rationale makes sense, I can send a v4 that adds a best-effort
spi_nor_restore() call and a kernel warning on lock acquisition failure.

Itai