On a board that keeps its kernel log on SPI NOR flash through mtdoops or mtdpstore, Linux 7.4-rc2 cannot store the log during a panic, because the SPI NOR core has no panic write method. A seven-patch series proposes one. As posted, it would work only above one controller driver, the Cadence XSPI driver. The series is not merged.
Status on 12 November 2026: version 4 is the latest posted version. Patch 1 is applied to the SPI maintainer’s tree. Paul Cercueil has asked the maintainers to wait for a version 5. Not merged.
A panic write is a flash write that the kernel performs after a panic has started. At that point interrupts are disabled, the other processors are stopped, and no code is allowed to sleep. The MTD layer has an interface for such a write. The SPI NOR core, which controls the boot flash on many embedded boards, does not implement it. Tanmay Jagdale of Marvell wrote a series that proposes to add it. Paul Cercueil of Bootlin co-developed the series and posted it.
Why mtdoops cannot store a panic log on SPI NOR today
Two MTD clients store the kernel log when the kernel fails. The older one is mtdoops (CONFIG_MTD_OOPS). It writes fixed-size records into the flash partition named by its mtddev parameter. The newer one is the MTD pstore backend, mtdpstore (CONFIG_MTD_PSTORE), which shows the records as files.
For an oops, mtdoops_do_dump() passes the record to a workqueue, and the record is written afterwards with the normal mtd_write(). After a panic no deferred work runs, so the code calls mtd_panic_write() directly.
In Linux 7.4-rc2, mtd_panic_write() in drivers/mtd/mtdcore.c first checks whether the flash driver provided a _panic_write method. If not, it returns -EOPNOTSUPP before it accesses the device. The SPI NOR core sets _read and _write in spi_nor_set_mtd_info(), but not _panic_write. On SPI NOR, mtdoops therefore prints “Cannot write from panic without panic_write” and stores nothing. mtdpstore reports a panic write failure.
| Event | Linux 7.4-rc2 | With version 4 as posted |
|---|---|---|
| Oops | Stored later by a workqueue, if the system keeps running | No change |
| Panic | Not stored (-EOPNOTSUPP) | Stored if the controller driver declares support and the write is not refused |
| Hang, or watchdog reset before the write ends | Not stored | Not stored |
There is a technical reason why the method is absent. A normal SPI NOR write acquires mutexes, may resume the controller through runtime power management, flushes the SPI message queue, and usually waits for a controller interrupt. None of these is allowed in a panic.
What the panic write series changes
The SPI memory layer. Patch 1 would add one flag in two places in include/linux/spi/spi-mem.h. A controller driver would declare that it can run a memory operation without sleeping and without interrupts, and each operation would have a matching flag.
struct spi_controller_mem_caps {
bool dtr;
bool ecc;
bool swap16;
bool per_op_freq;
bool secondary_op_tmpl;
bool no_cs_assertion;
bool panic_write;
};In spi_mem_exec_op(), an operation with the flag set would be rejected with -EOPNOTSUPP unless the controller declares the capability and implements exec_op(). It would be rejected with -EPERM in three cases: the device uses a GPIO chip select, one of the two controller mutexes (bus_lock_mutex, io_mutex) is held, or the controller is not runtime-active.
The SPI NOR core. Patch 2 would replace the loop that waits for the flash to become ready with poll_timeout_us(). Patch 3 would add spi_nor_panic_write(). It would be registered as _panic_write only for a flash that uses the standard write function through the SPI memory layer, and only when the controller declares the capability. The handler would return -EPERM if the SPI NOR lock is held or, with parallel locking, if another operation is in progress. Otherwise it would call the existing spi_nor_write(). That code would check the oops_panic_write flag, which mtd_panic_write() already sets. When the flag is set, the lock helpers would return immediately, the direct-mapping write would not be used, and the wait for the flash would use poll_timeout_us_atomic().
One controller driver. Patches 4 to 6 would change drivers/spi/spi-cadence-xspi.c, and patch 7 would change its device tree binding. The interrupt line would become optional, and the driver would poll status registers when there is no interrupt or when the operation is a panic write. It would then declare the capability. The series converts no other controller driver. The Cadence QSPI driver, spi-cadence-quadspi.c, is a separate driver and is not changed. The SPI NAND code is not changed either.
Review: message queue, runtime PM and memory allocation
Mark Brown, the SPI maintainer, gave the first review by a person. He noted that a panic write in version 1 would still flush the message queue and call runtime power management. Cercueil replied that the queue is not processed during a panic, so it can be ignored. Brown asked whether the other processors and the hardware are really in a known state: “I’m a bit nervous about assuming panic got things into a good state.” His concern was the case where the other processors were not actually stopped, though he added that this was perhaps not worth worrying about. Cercueil answered that panic handlers assume everything is stopped, and that the mutex check would detect a transfer that is in progress. Version 2, posted during this discussion, omitted the queue flush and the locking for a panic write.
The runtime power management check changed in each of the first three versions. Miquel Raynal suggested pm_runtime_get_if_active(), and version 2 used it. Sashiko, an automated review tool, reported that this function acquires a spinlock, and a stopped processor may still hold that lock. Cercueil proposed to refuse every controller that uses automatic runtime power management. Raynal did not like this, because by his count it would exclude 45 of more than 300 SPI controller drivers, but he accepted it for now. Cercueil then suggested pm_runtime_active(), Raynal agreed, and version 3 uses it.
Memory allocation was also changed after review. The octal DTR write path allocates a temporary buffer when the address or the length is odd. Sashiko reported that any allocation acquires locks that a stopped processor may still hold. Version 4 uses the existing SPI NOR bounce buffer instead.
On version 3, Brown noted that cdns_xspi_supports_op() reads device properties on kernels built with ACPI support, which acquires a lock and could deadlock in a panic. He said this need not stop the series, and Cercueil agreed to fix it separately.
Sashiko’s comments on version 4 have not received a reply. Among other points, they report a polling timeout of 1 millisecond that may be too short for large transfers, and an error bit that the polling path does not check.
Current status of the panic write series
Version 4 was posted on 16 October 2026 to the linux-mtd, linux-spi and linux-kernel lists. On 28 October Cercueil asked the maintainers not to apply it yet. He has a second Cadence XSPI series that contains fixes, and he wants it merged first so that the fixes can be backported. He then plans to rebase this series on it and post version 5.
However, on 5 November Brown applied patch 1, which adds the SPI memory flag. He also reported that patch 5 does not apply to the current code. We found patch 1 as commit 7c9cd0af6764 on the for-7.5 branch of his SPI tree, with a commit date of 9 November. It is not in Linux 7.4-rc2, and it was not in linux-next when we checked. The fixes series was posted as version 3 on 12 November. Version 5 of this series has not been posted.
Three steps remain: the fixes series must be accepted, version 5 must be posted, and the SPI NOR maintainers must review patches 2 and 3. No maintainer has stated a target release for the remaining six patches.
Which boards would gain a panic write
Most teams have nothing to change yet. A team that wants to read the code can fetch version 4 with b4.
raghu@techveda.org:~$ b4 am 20261016102917.171095-1-paul.cercueil@bootlin.comIf the series is merged as posted, three conditions determine whether a product will have a working panic write.
- The controller driver must declare support. The series converts only the Cadence XSPI driver. A board with any other SPI flash controller would behave as it does today, until its driver has an
exec_op()path that does not sleep and does not wait for an interrupt. The same is true for an out-of-tree controller driver. - The write can be refused. It would be refused if the flash uses a GPIO chip select, if the controller is runtime-suspended, or if a flash operation is in progress when the panic starts.
- The existing configuration would be used. The series adds no Kconfig option. A partition that is already assigned to mtdoops or mtdpstore would be written on each panic.
A team can check now what its product stores. On SPI NOR, mtdoops does not store a panic record, and it stores an oops record only if the system keeps running after the oops. Products that set panic_on_oops should expect no record in flash. A log kept in RAM does not depend on this series. We compared the options in Embedded Linux Log Storage: RAM, Flash or Remote?.
The series would not help with a hang, where no panic occurs. It would not help when a hardware watchdog resets the board before the write is complete.
What was checked and what could not be verified
We read the cover letters and the review replies of versions 1 to 4. We read patches 1, 2, 3, 6 and 7 of version 4 in full, and patches 4 and 5 in part. Present behaviour was read from the sources at the v7.4-rc2 tag.
We did not run anything on hardware. The mtdoops message is quoted from the source code, not from a board. The mail that announced patch 1 as applied names a different branch (for-7.4) and a commit identifier that we could not find. The cover letters do not state the test hardware.
Key takeaways
- In Linux 7.4-rc2 the SPI NOR core has no
_panic_writemethod, so mtdoops and mtdpstore cannot store a panic record on SPI NOR. - Only the Cadence XSPI driver would be converted, and the write can still be refused.
- Patch 1 is in the SPI maintainer’s tree. Nothing is in a released kernel.
Frequently asked questions
Does mtdoops work on SPI NOR flash today?
Partly. An oops record is written later by a workqueue, if the system keeps running. A panic needs mtd_panic_write(), which returns -EOPNOTSUPP because the SPI NOR core has no _panic_write method.
Has the SPI NOR panic write series been merged?
No. On 12 November 2026 patch 1 was on the for-7.5 branch of the SPI maintainer’s tree.
Which SPI controllers would support a panic write?
The series would convert only the Cadence XSPI driver. Any other controller driver would need its own change.
References
- [PATCH v4 0/7] spi: Add support for panic mem writes (lore.kernel.org thread)
- v3 thread
- v2 thread
- v1 thread
- [PATCH v3 0/6] spi: cadence-xspi: Fixes and ACPI changes
- Patch 1 as committed in the SPI maintainer’s tree
- drivers/mtd/mtdoops.c at v7.4-rc2
- drivers/mtd/mtdcore.c at v7.4-rc2
- drivers/mtd/spi-nor/core.c at v7.4-rc2
