Re: [PATCH v5 0/4] mmc: Add pstore backend for crash dump storage on eMMC
Adrian Hunter <[email protected]> Wed, 12 Aug 2026 11:26:22 +0300
| Newsgroups | org.kernel.vger.linux-mmc,org.kernel.vger.linux-kernel |
|---|---|
| Organization | Intel Finland Oy, Registered Address: c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo, Business Identity Code: 0357606 - 4, Domiciled in Helsinki |
| Message-ID | <[email protected]> |
On 11/08/2026 19:47, Florian Fainelli wrote: > Hi Ulf, > > On 6/10/26 10:01, Kamal Dasu wrote: >> >> >> On Wed, Jun 10, 2026 at 12:53 PM Kamal Dasu <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> On Wed, Apr 22, 2026 at 4:51 PM Kamal Dasu <[email protected] >> <mailto:[email protected]>> wrote: >> >> This series adds mmcpstore, a pstore backend driver that enables >> persistent storage of kernel crash logs on eMMC devices. When the >> kernel panics, pstore captures the kmsg dump and writes it directly >> to a dedicated MMC partition using polled I/O with interrupts >> disabled. >> >> Changes since v4 (addresses Ulf Hansson's feedback on the v4 panic >> host path, linux-mmc): >> - mmc_panic_claim_host(): log claimed, runtime suspend, and >> ongoing_mrq before claim; always call panic_prepare() when >> implemented so the host can drain or gracefully terminate >> in-flight requests, then force-claim. Vendor controllers may >> supply their own panic_prepare for platform-specific cases (1/4). >> - SDHCI: reference panic_prepare implementation; longer drain/reset >> timeouts; document panic helper return values in kernel-doc >> (2/4). >> - mmcpstore: single prepare/claim path; panic_complete() after >> panic_poll_completion() on panic writes (4/4). >> >> Changes since v3: >> - Fixed kernel-doc warnings reported by kernel test robot: >> - Added missing @param descriptions for sdhci_panic_prepare(), >> sdhci_panic_poll_completion(), sdhci_panic_complete() (patch 2) >> - Added missing @sect_offset param doc for >> mmcpstore_do_request_internal() (patch 4) >> - Fixed kernel-doc function name mismatch: mmcpstore_read() -> >> mmcpstore_read_zone() (patch 4) >> - Added missing @disk param doc for mmcpstore_card_add() >> (patch 4) >> - Removed unused 'offset_bytes' variable in >> mmcpstore_register_for_card() (patch 4) >> >> Changes since v2 (RFC): >> - Rebased onto v7.0-rc — no longer reverts any existing MMC core >> or SDHCI changes (v1/v2 accidentally reverted recent upstream >> commits due to being based on an older tree) >> - Removed all erase/bitmap tracking logic — MMC/eMMC is managed >> flash and does not need erase-before-write; the pstore_zone >> framework handles zone management internally >> - Uses standard MMC core request path (mmc_start_request) instead >> of hand-building mmc_request structs; panic-context I/O is >> handled through proper mmc_host_ops callbacks rather than ad-hoc >> code in the driver >> - Added panic-context ops to mmc_host_ops and sdhci_ops for clean >> separation of panic and normal I/O paths >> - Fixed deadlocks caused by spinlock contention during panic >> (lockless mmc_panic_claim_host using WRITE_ONCE) >> - Fixed data corruption in pstore recovery (zlib_inflate failures) >> by letting the normal sdhci_request() path run instead of a >> custom panic request handler >> - Added PM suspend/resume support with eMMC re-initialization >> - Supports module loading or builtin loading of the driver >> - Added MAINTAINERS entry >> - Split into 4-patch series for reviewability >> >> The series is structured as follows: >> >> Patch 1 adds panic-context operations to struct mmc_host_ops and a >> lockless mmc_panic_claim_host() for use during kernel panic when >> other CPUs are stopped and may hold locks. Host drivers may replace >> panic_prepare with vendor-specific code where needed. >> >> Patch 2 implements the SDHCI reference panic_prepare (graceful >> termination of in-flight work, then polled completion paths); other >> MMC host drivers use the same mmc_host_ops hooks with their own >> panic_prepare where the hardware differs. >> >> Patch 3 adds mmc_blk_get_card_by_name() helper to look up an >> mmc_card from a block device name, used by the mmcpstore module >> path for card discovery. >> >> Patch 4 adds the mmcpstore driver itself, which registers with the >> pstore_blk framework and handles panic writes, PM suspend/resume, >> and dual-path registration (direct probe hook for builtin, >> mmc_blk_get_card_by_name() for module). Also adds probe/remove >> hooks in block.c and declarations in block.h for the builtin path. >> >> Tested on Broadcom STB platforms (ARM64) with SDHCI controllers, >> verified panic dump recovery across multiple panic/reboot cycles >> with kmsg, pmsg, and console pstore; also tested with concurrent >> I/O stress before panic. >> >> Previous submissions and related work: >> RFC v1: https://lore.kernel.org/linux- >> mmc/[email protected]/ <https:// >> lore.kernel.org/linux-mmc/20221216212738.7928-1- >> [email protected]/> >> RFC v2: https://lore.kernel.org/linux- >> mmc/[email protected]/ <https:// >> lore.kernel.org/linux-mmc/20221222185948.12717-1- >> [email protected]/> >> v3: https://lore.kernel.org/linux- >> mmc/[email protected]/ <https:// >> lore.kernel.org/linux-mmc/20260319185705.1516950-1- >> [email protected]/> >> v4: linux-mmc (same thread as v3; superseded by this v5) >> Marvell MMC pstore attempt (2020): >> https://lore.kernel.org/linux-mmc/20201207115753.21728-1- >> [email protected]/ <https://lore.kernel.org/linux- >> mmc/[email protected]/> >> pstore/blk documentation: >> https://www.kernel.org/doc/html/latest/admin-guide/pstore- >> blk.html <https://www.kernel.org/doc/html/latest/admin-guide/ >> pstore-blk.html> >> >> Kamal Dasu (4): >> mmc: core: Add panic-context host operations for pstore backends >> mmc: sdhci: Implement panic-context write support >> mmc: block: Add helper to look up mmc_card by device name >> mmc: core: Add MMC pstore backend driver >> >> MAINTAINERS | 6 + >> drivers/mmc/core/Kconfig | 12 + >> drivers/mmc/core/Makefile | 1 + >> drivers/mmc/core/block.c | 56 ++ >> drivers/mmc/core/block.h | 18 + >> drivers/mmc/core/core.c | 54 ++ >> drivers/mmc/core/mmcpstore.c | 1511 ++++++++++++++++++++++++++ >> ++++++++ >> drivers/mmc/host/sdhci.c | 173 +++- >> drivers/mmc/host/sdhci.h | 6 + >> include/linux/mmc/host.h | 12 + >> 10 files changed, 1845 insertions(+), 4 deletions(-) >> create mode 100644 drivers/mmc/core/mmcpstore.c >> >> -- 2.34.1 >> >> >> >> >> Ulf, >> >> I'm resending a gentle reminder regarding the v5 patch series for mmcpstore. >> >> This version addresses your previous feedback on the v4 panic host path and includes several key stability improvements: >> >> - Implements a lockless mmc_panic_claim_host using WRITE_ONCE to avoid deadlocks during panic. >> - Adds panic_prepare to the host ops to ensure in-flight requests are drained and runtime PM states are handled before panic writes. >> - Uses standard MMC core request paths with polling-based completion for robust I/O during a crash. >> - Includes full PM suspend/resume support with eMMC re-initialization. >> >> The series has been tested thoroughly on Broadcom STB platforms (ARM64), verifying reliable recovery of kmsg, pmsg, and console logs across multiple panic cycles. >> >> Please let me know if you need any further information or if there are additional changes required for acceptance. > > Is there anything we could do here to move this forward? We have large number of devices in the field that make use of that feature and we would really like for this to be included upstream and usable by others as well. > > Thanks! Perhaps start by describing the problem. pstore_blk already supports block devices including mmc block devices, right? Have you any information on how well that works in practice? Is a dedicated mmc pstore back end really needed? What are the generic requirements for a pstore backend? How do they map to requirements for mmc? How are big obstacles handled like: - the device is in use - the device is runtime suspended - the controller is runtime suspended - a runtime power management transition is underway - a system power management transition is underway - reset or recovery is in progress - the panic originates in the mmc subsystem - switching emmc partitions - device tuning / re-tuning - maybe other things? Is it so that in some cases the pstore back end needs to leave the mmc system in an operational state? Whereas in a panic/oops it could leave it broken?