mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


             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®