All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Michael J. Ruhl" <michael.j.ruhl@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v11 05/20] platform/x86/intel/pmt: Do not remap when using callbacks
Date: Wed, 23 Sep 2026 18:29:45 +0000	[thread overview]
Message-ID: <20260923182945.CB55D1F0089E@smtp.kernel.org> (raw)
In-Reply-To: <20260923181115.2514193-27-michael.j.ruhl@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] intel_aet: silent telemetry read failure for PMT devices using callbacks
--

commit 43eab3aee86b2e3202e1e7b01c4ce97411570441
Author: Michael J. Ruhl <michael.j.ruhl@intel.com>
Subject: platform/x86/intel/pmt: Do not remap when using callbacks

A callback indicates that the parent driver is responsible for accessing
the data area. Creating a PMT memory remap is redundant. If a read_telem
callback has been provided, do not create a remap.

> diff --git a/drivers/platform/x86/intel/pmt/class.c b/drivers/platform/x86/intel/pmt/class.c
> index 402d51df834a6..1c7a372b4fc42 100644
> --- a/drivers/platform/x86/intel/pmt/class.c
> +++ b/drivers/platform/x86/intel/pmt/class.c
[ ... ]
> @@ -403,14 +403,19 @@ static int intel_pmt_dev_register(struct intel_pmt_entry *entry,
>  	if (!entry->size)
>  		return 0;
>  
> -	res.start = entry->base_addr;
> -	res.end = res.start + entry->size - 1;
> -	res.flags = IORESOURCE_MEM;
> +	/*
> +	 * The read_telem callback is responsible for this mapping, and may have
> +	 * different requirements for use. If the callback is present do not
> +	 * create the map.
> +	 */
> +	if (!(entry->cb && entry->cb->read_telem)) {
> +		struct resource res = DEFINE_RES_MEM(entry->base_addr, entry->size);
>  
> -	entry->base = devm_ioremap_resource(dev, &res);
> -	if (IS_ERR(entry->base)) {
> -		ret = PTR_ERR(entry->base);
> -		goto fail_ioremap;
> +		entry->base = devm_ioremap_resource(dev, &res);
> +		if (IS_ERR(entry->base)) {
> +			ret = PTR_ERR(entry->base);
> +			goto fail_ioremap;
> +		}
>  	}
>  

[Severity: Medium]
When a read_telem callback is provided, entry->base remains NULL.
Could this silently break telemetry reads for Intel AET?

If entry->base is NULL, it propagates to the telemetry endpoint:

drivers/platform/x86/intel/pmt/telemetry.c:pmt_telem_add_endpoint() {
    ...
    ep->base = entry->base;
    ...
}

Then pmt_copy_region() populates the telemetry region with this NULL address:

drivers/platform/x86/intel/pmt/telemetry.c:pmt_copy_region() {
    ...
    region->addr = entry->ep->base;
    ...
}

Finally, in intel_aet_read_event(), the region is skipped because the address is
NULL:

arch/x86/kernel/cpu/resctrl/intel_aet.c:intel_aet_read_event() {
    ...
    for (int i = 0; i < e->pfg->count; i++) {
        if (!e->pfg->regions[i].addr)
            continue;
    ...
}

Because Intel AET strictly requires direct MMIO, it cannot support abstracted
callbacks. This results in a silent failure to collect telemetry data from
AET-monitored devices that use callbacks, since intel_aet_read_event() will
skip the region and return -EINVAL on every read request.

>  	sysfs_bin_attr_init(&entry->pmt_bin_attr);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923181115.2514193-22-michael.j.ruhl@intel.com?part=5

  reply	other threads:[~2026-09-23 18:29 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 18:11 [PATCH v11 00/20] Crescent Island PMT support Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 01/20] platform/x86/intel/pmt: complete pcidev to device update Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 02/20] platform/x86/intel/pmt: refactor rmw with a return value Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 03/20] platform/x86/intel/pmt: refactor rc " Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 04/20] platform/x86/intel/pmt: Add register access callbacks Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 05/20] platform/x86/intel/pmt: Do not remap when using callbacks Michael J. Ruhl
2026-09-23 18:29   ` sashiko-bot [this message]
2026-09-29 13:12   ` Rodrigo Vivi
2026-09-23 18:11 ` [PATCH v11 06/20] drm/xe/vsec: Do not register BMG PMT for VF Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 07/20] drm/xe/vsec: Correct locking order Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 08/20] drm/xe/vsec: Use correct pm state get Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 09/20] drm/xe/vsec: Add DOC text for VSEC Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 10/20] drm/xe/vsec: Support possible hotplug exit Michael J. Ruhl
2026-09-23 18:18   ` sashiko-bot
2026-09-23 18:11 ` [PATCH v11 11/20] drm/xe/vsec: Refactor BattleMage PMT defines Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 12/20] drm/xe/vsec: Update VSEC probe order Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 13/20] drm/xe/vsec: Add base_offset to allow for more flexibilty Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 14/20] drm/xe/vsec: Support Crescent Island PMT Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 15/20] drm/xe/vsec: Crescent Island PMT decode Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 16/20] drm/xe/vsec: Crescent Island PMT callbacks Michael J. Ruhl
2026-09-23 18:28   ` sashiko-bot
2026-09-23 18:11 ` [PATCH v11 17/20] drm/xe/vsec: Support late bind fw information Michael J. Ruhl
2026-09-23 18:31   ` sashiko-bot
2026-09-30  4:09   ` Rodrigo Vivi
2026-09-30 12:57     ` Ruhl, Michael J
2026-09-30 13:04       ` Rodrigo Vivi
2026-09-23 18:11 ` [PATCH v11 18/20] drm/xe/vsec: Add PMT GUID internal access Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 19/20] drm/xe/vsec: Update PMT " Michael J. Ruhl
2026-09-23 18:11 ` [PATCH v11 20/20] drm/xe/vsec: Refactor platform check Michael J. Ruhl
2026-09-23 18:20 ` ✗ CI.checkpatch: warning for Crescent Island PMT support (rev13) Patchwork
2026-09-23 18:22 ` ✓ CI.KUnit: success " Patchwork
2026-09-23 20:26 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-24  8:49 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-29  8:12 ` [PATCH v11 00/20] Crescent Island PMT support Ilpo Järvinen
2026-09-29 13:20   ` Rodrigo Vivi
2026-09-30  6:23     ` Ilpo Järvinen

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=20260923182945.CB55D1F0089E@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=michael.j.ruhl@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.