From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: "David E. Box" <david.e.box@linux.intel.com>,
"Ruhl, Michael J" <michael.j.ruhl@intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
platform-driver-x86@vger.kernel.org, rodrigo.vivi@intel.com,
ayaz.siddiqui@intel.com, syed.abdul.muqthyar.ahmed@intel.com,
intel-xe@lists.freedesktop.org, Hans de Goede <hansg@kernel.org>
Subject: Re: [PATCH 0/3] platform/x86/intel/pmt: Fix crashlog regressions and add completion uevent
Date: Mon, 12 Oct 2026 18:54:20 +0300 (EEST) [thread overview]
Message-ID: <3aa06f60-12a3-23c5-9f5e-dd3d2b1d0448@linux.intel.com> (raw)
In-Reply-To: <20261001220351.1592138-1-david.e.box@linux.intel.com>
On Thu, 1 Oct 2026, David E. Box wrote:
> This series adds a uevent so userspace can find out when an Intel PMT
> crashlog is available without polling. It also fixes two regressions
> from the v7.1 vsec rework that prevent the crashlog path from being
> used at all.
>
> Patches 1 and 2 are fixes, tagged for stable:
>
> - Patch 1 fixes a NULL pointer dereference on any read of a crashlog
> sysfs data file. Commit 353042d54d82 ("platform/x86/intel/vsec:
> Switch exported helpers from pci_dev to device") started using
> entry->ep->dev, but only telemetry entries allocate an endpoint.
>
> - Patch 2 fixes an inverted return value test of
> intel_vsec_walk_header() in intel_vsec_get_features(). On devices
> without DVSEC/VSEC capabilities that describe their features through
> device_data, probe fails with -ENODEV and the auxiliary devices it
> created are torn down again.
>
> Patch 3 is the new feature. It emits a KOBJ_CHANGE uevent on the
> crashlog<x> device when a completed crashlog is found at probe, or when
> a manually triggered capture completes. The event carries
> INTEL_PMT_CRASHLOG_EVENT=PRESENT and INTEL_PMT_CRASHLOG_COMPLETE=1, and
> the ABI documentation is updated to match.
>
> The fixes are sent together with the feature because patch 3 cannot be
> tested without them. Crashlog data cannot be read without patch 1.
> Upcoming hardware with crashlog support has no DVSEC/VSEC capabilities
> and describes its features through device_data, so it hits the bug
> fixed by patch 2. Patches 1 and 2 do not depend on patch 3 and can be
> applied to the fixes branch on their own if preferred.
>
> Testing: the series was tested in an emulated (QEMU) environment,
> covering both the probe-time uevent with a completed crashlog present
> and the uevent after a manual trigger completes. Hardware with this
> crashlog support is available, but testing on it is still pending.
>
> David E. Box (3):
> platform/x86/intel/pmt: Fix NULL dereference when reading crashlog
> data
> platform/x86/intel/vsec: Fix inverted walk_header() test in
> get_features()
> platform/x86/intel/pmt: Notify userspace when crashlogs complete
I took the 2nd patch but the others seem to need more discussion/work
given the recent changes.
--
i.
prev parent reply other threads:[~2026-10-12 15:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 22:03 [PATCH 0/3] platform/x86/intel/pmt: Fix crashlog regressions and add completion uevent David E. Box
2026-10-01 22:03 ` [PATCH 1/3] platform/x86/intel/pmt: Fix NULL dereference when reading crashlog data David E. Box
2026-10-02 12:43 ` Ruhl, Michael J
2026-10-01 22:03 ` [PATCH 2/3] platform/x86/intel/vsec: Fix inverted walk_header() test in get_features() David E. Box
2026-10-02 20:45 ` Ruhl, Michael J
2026-10-01 22:03 ` [PATCH 3/3] platform/x86/intel/pmt: Notify userspace when crashlogs complete David E. Box
2026-10-02 9:13 ` sashiko-bot
2026-10-02 20:59 ` Ruhl, Michael J
2026-10-01 22:11 ` ✗ CI.checkpatch: warning for platform/x86/intel/pmt: Fix crashlog regressions and add completion uevent Patchwork
2026-10-01 22:13 ` ✓ CI.KUnit: success " Patchwork
2026-10-12 15:54 ` Ilpo Järvinen [this message]
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=3aa06f60-12a3-23c5-9f5e-dd3d2b1d0448@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=ayaz.siddiqui@intel.com \
--cc=david.e.box@linux.intel.com \
--cc=hansg@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.