Re: [PATCH v5 0/4] mmc: Add pstore backend for crash dump storage on eMMC

[Kamal Dasu]

On Wed, Aug 12, 2026 at 4:26 AM Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>
> 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 <kamal.dasu@xxxxxxxxxxxx <mailto:kamal.dasu@xxxxxxxxxxxx>> wrote:
> >>
> >>
> >>
> >>     On Wed, Apr 22, 2026 at 4:51 PM Kamal Dasu <kamal.dasu@xxxxxxxxxxxx
> >>     <mailto:kamal.dasu@xxxxxxxxxxxx>> 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/20221216212738.7928-1-kdasu.kdev@xxxxxxxxx/ <https://
> >>         lore.kernel.org/linux-mmc/20221216212738.7928-1-
> >>         kdasu.kdev@xxxxxxxxx/>
> >>            RFC v2: https://lore.kernel.org/linux-
> >>         mmc/20221222185948.12717-1-kdasu.kdev@xxxxxxxxx/ <https://
> >>         lore.kernel.org/linux-mmc/20221222185948.12717-1-
> >>         kdasu.kdev@xxxxxxxxx/>
> >>            v3: https://lore.kernel.org/linux-
> >>         mmc/20260319185705.1516950-1-kamal.dasu@xxxxxxxxxxxx/ <https://
> >>         lore.kernel.org/linux-mmc/20260319185705.1516950-1-
> >>         kamal.dasu@xxxxxxxxxxxx/>
> >>            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-
> >>         bbudiredla@xxxxxxxxxxx/ <https://lore.kernel.org/linux-
> >>         mmc/20201207115753.21728-1-bbudiredla@xxxxxxxxxxx/>
> >>            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?
>
pstore must write kmsg to eMMC from inside panic() -- IRQs and
preemption already disabled, other CPUs stopped -- and complete
without sleeping, blocking on a lock, or waiting on an interrupt.
It lets you attach one (blkdev=/dev/mmcblk0pN). Attaching isn't the
same as working during a panic.
Not at all for an actual panic. Its own code says so on attach:
"attached %s (...) (no dedicated panic_write!)" (fs/pstore/blk.c:312).
Its write path also returns -EBUSY whenever irqs_disabled() -- always
true once panic() has run -- and no panic_write is registered, so
pstore's panic dispatch has nothing to call.

"Is a dedicated mmc backend really needed? "
Yes. pstore-blk.rst already documents that panic capture requires a
dedicated, polled, lock-free panic_write; mtdpstore is the existing
in-tree backend doing that for flash. This is the same pattern
applied to MMC.

> What are the generic requirements for a pstore backend?  How do they
> map to requirements for mmc?
>

panic_write must run synchronously, one CPU, IRQs/preempt already
off, complete-or-fail before returning: no sleep, no blocking lock,
no allocation, no interrupt-driven completion. That rules out
mmc_claim_host() (sleeps), mmc_wait_for_req()/mmc_wait_for_cmd()
(wait_for_completion -> schedule()), and blk-mq/mmc_queue (IRQ +
workqueue driven). The panic path instead builds raw mmc commands and
polls host registers directly for completion.

> How are big obstacles handled like:
> - the device is in use

force-claimed via WRITE_ONCE (host
lock not taken); in-flight command is drained with a bounded poll
(500ms) then aborted via software reset, not gracefully finished.

> - the device is runtime suspended
detected (pm_runtime_suspended()) and
logged; nothing resumes power before the write is attempted.

> - the controller is runtime suspended
same -- detected, not acted on.
Runtime PM transition underway: no check beyond that same read.

> - a runtime power management transition is underway
no check beyond that same read.

> - a system power management transition is underway
A PM notifier blocks read/write during PM_SUSPEND_PREPARE and re-inits
the card via
pm_runtime_get_sync() on PM_POST_SUSPEND -- but this notifier is
entirely separate from, and not consulted by, the panic write path.

> - reset or recovery is in progress
no interaction with mmc_hw_reset() or CQE recovery anywhere in the panic path.

> - the panic originates in the mmc subsystem

mmc_host->lock is bypassed  entirely (WRITE_ONCE, no lock taken) for
exactly this reason.
sdhci_host->lock is not treated the same way -- it's taken with a
plain spin_lock_irqsave(), no trylock, no bypass.

> - switching emmc partitions

the panic path can switch to its own  target partition (raw CMD6 +
busy poll). The previously-active
partition is saved (original_part_config) but never read back or
restored anywhere in the file.

> - device tuning / re-tuning

mmc_start_request(), called directly by the panic path, unconditionally calls
mmc_retune(), which if host->retune_now is set calls into
mmc_execute_tuning() ->
mmc_wait_for_req() -> wait_for_completion() -> schedule(). Nothing
checks or clears retune_now beforehand.

> - maybe other things?
>
None of the above interact with each other either
e.g.a partition switch and a runtime-suspended controller occurring
together are each handled (or not) independently, not as a
combined case.

> 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?
>
Nothing in the code releases the forced claim, re-initializes the
card, or restores state after a panic write. It does two bounded
delays and returns, leaving host->claimed forced, CQE off if
disabled, and the card on whichever partition was last selected. The
The implicit assumption is that a reboot follows eventually.

Thanks
Kamal

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature