From: "David E. Box" <david.e.box@linux.intel.com>
To: ilpo.jarvinen@linux.intel.com, david.e.box@linux.intel.com,
linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org, rodrigo.vivi@intel.com,
michael.j.ruhl@intel.com, ayaz.siddiqui@intel.com,
syed.abdul.muqthyar.ahmed@intel.com,
intel-xe@lists.freedesktop.org, hansg@kernel.org
Subject: [PATCH v2 0/1] platform/x86/intel/pmt: Notify userspace when crashlogs complete
Date: Thu, 22 Oct 2026 19:38:31 -0700 [thread overview]
Message-ID: <cover.1792721526.git.david.e.box@linux.intel.com> (raw)
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.
v1 was a three-patch series. Patches 1 and 2 are no longer part of it:
- Patch 1 (NULL dereference when reading crashlog data) is dropped in
favor of Michael's "platform/x86/intel/pmt: complete pcidev to
device update" (b86e5062cb88), which fixes the same bug.
- Patch 2 (inverted walk_header() test in get_features()) has been
applied as 3678e39c6aae.
Both are in the base of this posting, review-ilpo-next. The patch also
applies cleanly to for-next.
Testing: the patch was tested in an emulated (QEMU) environment on a
kernel with CONFIG_PROVE_LOCKING, covering the probe-time event, the
event after a manual trigger completes, triggers rejected while a log
is complete or the device is disabled, clear, trigger=0 and rearm while
the trigger poll is running, expiry of the poll window, module removal
with the poll pending, and re-probe. Hardware with this crashlog
support is available, but testing on it is still pending.
V2 changes:
- Replaced the two uevent variables with a single
INTEL_PMT_CRASHLOG_COMPLETE. INTEL_PMT_CRASHLOG_EVENT=PRESENT and
COMPLETE=1 were both fixed and carried no information beyond the
event itself.
- Emit COMPLETE=0 when a manual trigger does not complete within the
poll window, so userspace is not left waiting.
- Reject manual triggers until probe has finished setting up the
entry. This closes a window where a trigger during
intel_pmt_dev_create() could queue work against a device freed by
its error path (reported by sashiko on v1).
- Dropped the cancel_*_sync() calls on the intel_pmt_dev_create()
failure and skip paths. They ran after the device was already
freed, but with triggers now rejected until setup completes no work
can be pending there.
- End the trigger poll without an event when the log is cleared or
rearmed while it is running.
- Cancel a stale poll only after the new trigger has been written, so
a failed trigger leaves the previous poll in place.
- Run the probe-time check under control_mutex, in the same critical
section that enables triggers.
- Run the poll on the freezable workqueue so it does not read the
device during suspend.
- Rebased onto review-ilpo-next and adapted to the crashlog register
helpers now returning errors (Michal's additions). A failed status
read counts as not complete.
- Rewrote the ABI
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 | 32 ++++
drivers/platform/x86/intel/pmt/crashlog.c | 138 +++++++++++++++++-
2 files changed, 165 insertions(+), 5 deletions(-)
base-commit: 9d3475065167197742b0882aff21cf8e78393277
--
2.43.0
next reply other threads:[~2026-10-23 2:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 2:38 David E. Box [this message]
2026-10-23 2:38 ` [PATCH v2 1/1] " David E. Box
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1792721526.git.david.e.box@linux.intel.com \
--to=david.e.box@linux.intel.com \
--cc=ayaz.siddiqui@intel.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.j.ruhl@intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=syed.abdul.muqthyar.ahmed@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®