From: sashiko-bot@kernel.org
To: "Michael J. Ruhl" <michael.j.ruhl@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 08/10] drm/xe/vsec: Crescent Island PMT callbacks
Date: Wed, 12 Aug 2026 19:57:09 +0000 [thread overview]
Message-ID: <20260812195710.42D571F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812193742.2170188-20-michael.j.ruhl@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Improper MMIO access for 32-bit control registers using byte-wise copies (memcpy_toio/memcpy_fromio).
--
--- Patch [8]: [PATCH v2 08/10] drm/xe/vsec: Crescent Island PMT callbacks ---
commit 664ab77147de6f456af0ceaeae6a996ddd3d6a40
Author: Michael J. Ruhl <michael.j.ruhl@intel.com>
drm/xe/vsec: Crescent Island PMT callbacks
This commit introduces callbacks to get the status and control information
for CRI PMT usage. It adds the glue logic to register the CRI PMT
functionality in the xe driver.
> diff --git a/drivers/gpu/drm/xe/xe_vsec.c b/drivers/gpu/drm/xe/xe_vsec.c
> index dc42b9492428a..578d59048b39c 100644
> --- a/drivers/gpu/drm/xe/xe_vsec.c
> +++ b/drivers/gpu/drm/xe/xe_vsec.c
[ ... ]
> +static int xe_pmt_read_reg(struct device *dev, u32 guid, u32 *reg, u32 offset)
> +{
[ ... ]
> + xe_pm_runtime_get(xe);
> + mutex_lock(&xe->pmt.lock);
> +
> + xe->soc_remapper.set_telem_region(xe, CRI_IDX_TELEM_DISCOVERY);
> +
> + memcpy_fromio(reg, disc_addr, sizeof(*reg));
[Severity: High]
Will this cause unsupported requests or return garbage on some platforms?
Using memcpy_fromio() for a 32-bit register read often falls back to
byte-wise transactions (like rep movsb) instead of a single 32-bit atomic
transaction. For MMIO control registers, issuing four 1-byte PCIe
transactions can cause the hardware to drop the request.
Should this use readl() or the driver's xe_mmio_read32() wrapper instead
to guarantee the correct 32-bit transaction width?
> +
> + mutex_unlock(&xe->pmt.lock);
> + xe_pm_runtime_put(xe);
> +
> +dev_exit:
> + drm_dev_exit(idx);
> +
> + return ret;
> +}
> +
> +static int xe_pmt_write_reg(struct device *dev, u32 guid, u32 reg, u32 offset)
> +{
[ ... ]
> + xe_pm_runtime_get(xe);
> + mutex_lock(&xe->pmt.lock);
> +
> + xe->soc_remapper.set_telem_region(xe, CRI_IDX_TELEM_DISCOVERY);
> +
> + memcpy_toio(disc_addr, ®, sizeof(reg));
[Severity: High]
Does this have the same byte-wise transaction issue?
Similar to the read path above, using memcpy_toio() for a single 32-bit
register write can result in 4 byte-sized MMIO writes. Should this use
writel() or xe_mmio_write32() to ensure a single 32-bit atomic write?
> +
> + mutex_unlock(&xe->pmt.lock);
> + xe_pm_runtime_put(xe);
> +
> +dev_exit:
> + drm_dev_exit(idx);
> +
> + return ret;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812193742.2170188-12-michael.j.ruhl@intel.com?part=8
next prev parent reply other threads:[~2026-08-12 22:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 19:37 [PATCH v2 00/10] Crescent Island PMT support Michael J. Ruhl
2026-08-12 19:37 ` [PATCH v2 01/10] platform/x86/intel/pmt: complete pcidev to device update Michael J. Ruhl
2026-08-12 19:37 ` [PATCH v2 02/10] platform/x86/intel/pmt: Add register access callbacks Michael J. Ruhl
2026-08-12 19:49 ` sashiko-bot
2026-08-12 19:37 ` [PATCH v2 03/10] drm/xe/vsec: Protect against missing config Michael J. Ruhl
2026-08-12 19:37 ` [PATCH v2 04/10] drm/xe/vsec: Use correct pm state get Michael J. Ruhl
2026-08-12 19:37 ` [PATCH v2 05/10] drm/xe/vsec: Support possible hotplug exit Michael J. Ruhl
2026-08-12 19:51 ` sashiko-bot
2026-08-12 19:37 ` [PATCH v2 06/10] drm/xe/vsec: Support Crescent Island PMT Michael J. Ruhl
2026-08-12 19:49 ` sashiko-bot
2026-08-12 19:37 ` [PATCH v2 07/10] drm/xe/vsec: Crescent Island PMT decode Michael J. Ruhl
2026-08-12 19:51 ` sashiko-bot
2026-08-12 19:37 ` [PATCH v2 08/10] drm/xe/vsec: Crescent Island PMT callbacks Michael J. Ruhl
2026-08-12 19:57 ` sashiko-bot [this message]
2026-08-12 19:37 ` [PATCH v2 09/10] drm/xe/vsec: Support late bind fw information Michael J. Ruhl
2026-08-12 19:54 ` sashiko-bot
2026-08-12 20:12 ` Ruhl, Michael J
2026-08-12 19:37 ` [PATCH v2 10/10] drm/xe/vsec: Update PMT internal access for CRI Michael J. Ruhl
2026-08-12 20:04 ` sashiko-bot
2026-08-12 20:24 ` ✓ CI.KUnit: success for Crescent Island PMT support (rev4) Patchwork
2026-08-12 21:16 ` ✓ Xe.CI.BAT: " Patchwork
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=20260812195710.42D571F000E9@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.