[PATCH v3 0/1] platform/x86/intel/pmt: Notify userspace when crashlogs complete

["David E. Box" <david.e.box@linux.intel.com>]

This patch adds a uevent so userspace can find out when an Intel PMT
crashlog is available without polling.

It emits a KOBJ_CHANGE uevent on the crashlog<x> device carrying
INTEL_PMT_CRASHLOG_COMPLETE. The value is 1 when a completed crashlog is
found at probe, or when a manually triggered capture completes. The value
is 0 when a manual trigger does not complete within the 5 second poll
window. The ABI documentation is updated to match.

The main change in v3 is that the probe-time check no longer reads the
crashlog registers from probe. The register access callbacks added by
Michael's "platform/x86/intel/pmt: Add register access callbacks"
(7fdfccf87676) are there for the upcoming xe support for Crescent Island
(CRI). That support implements read_reg() and holds the lock it takes
across intel_vsec_register() when it registers late, after its firmware
is ready. With pmt_crashlog already loaded, crashlog probe runs
synchronously inside that call, and the v2 probe-time read deadlocked on
the lock its own caller held. Michael found this on CRI. In v3 the check
runs from a work item, which waits for registration to finish.

One rule follows from this and is noted in the code: a parent must not
hold its read_reg() lock while removing the crashlog device, because
remove waits for these work items. The CRI xe code only removes the
device under that lock if devm_add_action_or_reset() fails inside
intel_vsec_add_aux().

Testing: Michael tested v3 on CRI hardware. It was also tested in QEMU
on a kernel with CONFIG_PROVE_LOCKING, covering the cases listed for v2
plus disabling the crashlog during the trigger poll. A test parent
driver modelled the CRI late-bind path: read_reg() callbacks under a
mutex held across intel_vsec_register(), a slow registration that keeps
the lock held after the device appears, and a trigger that reaches
control_mutex before the probe-time check.

Tool use: an LLM coding assistant was used to analyze the deadlock,
draft the changes and the QEMU tests, and review the patch with
sashiko. I reviewed and tested the result.

V3 changes:
  - Run the probe-time check from a work item queued at the end of
    probe instead of from probe, so a read_reg() callback is never
    called from a synchronous probe that may run under the parent's
    lock (reported and tested by Michael on CRI).
  - Queue the probe-time check on the freezable workqueue, like the
    poll (sashiko).
  - Enable triggers once probe has created every entry, rather than per
    entry, so abort_probe never waits on a work item blocked on its
    caller's lock.
  - If a trigger is accepted before the probe-time check runs, the
    check skips its notification. The trigger's poll reports the
    capture, so it is not also reported as found at probe.
  - Disabling the crashlog while the trigger poll runs ends the poll
    without an event, like clear and rearm (sashiko).
  - ABI: note that events may be merged, list writing 0 to trigger and
    disabling as ending the poll, and update Date and KernelVersion.
  - Rebased onto review-ilpo-next. The patch also applies cleanly to
    for-next.

v2: https://lore.kernel.org/all/cover.1792721526.git.david.e.box@linux.intel.com/
v1: https://lore.kernel.org/all/20261001220351.1592138-1-david.e.box@linux.intel.com/

David E. Box (1):
  platform/x86/intel/pmt: Notify userspace when crashlogs complete

 .../ABI/testing/sysfs-class-intel_pmt         |  35 ++++
 drivers/platform/x86/intel/pmt/crashlog.c     | 180 +++++++++++++++++-
 2 files changed, 209 insertions(+), 6 deletions(-)


base-commit: 5680519168f65666d2c03cc6ed8fe2b7052aee12
-- 
2.53.0