From: sashiko-bot@kernel.org
To: "Karthik Poosa" <karthik.poosa@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 2/5] drm/xe/hwmon: Use VRAM temperature sensor count from thermal config on CRI
Date: Wed, 02 Sep 2026 18:10:21 +0000 [thread overview]
Message-ID: <20260902181022.28C201F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260902175507.3910573-3-karthik.poosa@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] VRAM temperature sensors will not be exposed on Crescent Island (CRI) platforms because `xe_hwmon_get_reg()` lacks `REG_TEMP` support for `XE_CRESCENTISLAND`.
- [Medium] On Battlemage (BMG) platforms, all VRAM temperature sensors will be silently hidden if the thermal PCODE mailbox initialization fails.
--
commit 426a936975a4587d5003554dc21e461abf340940
Author: Karthik Poosa <karthik.poosa@intel.com>
drm/xe/hwmon: Use VRAM temperature sensor count from thermal config on CRI
Read the number of VRAM temperature sensor channels from the second byte
of READ_THERMAL_CONFIG on CRI platforms. Use the reported count to avoid
exposing hwmon attributes for unavailable VRAM temperature sensors, while
retaining the maximum supported channel count on non-CRI platforms.
> diff --git a/drivers/gpu/drm/xe/xe_hwmon.c b/drivers/gpu/drm/xe/xe_hwmon.c
> index 768f6d68b2916..51a6664eec485 100644
> --- a/drivers/gpu/drm/xe/xe_hwmon.c
> +++ b/drivers/gpu/drm/xe/xe_hwmon.c
[ ... ]
> @@ -271,7 +275,7 @@ static struct xe_reg xe_hwmon_get_reg(struct xe_hwmon *hwmon, enum xe_hwmon_reg
> return BMG_PACKAGE_TEMPERATURE;
> else if (channel == CHANNEL_VRAM)
> return BMG_VRAM_TEMPERATURE;
> - else if (in_range(channel, CHANNEL_VRAM_N, MAX_VRAM_CHANNELS))
> + else if (in_range(channel, CHANNEL_VRAM_N, hwmon->temp.vram_count))
> return BMG_VRAM_TEMPERATURE_N(channel - CHANNEL_VRAM_N);
> } else if (xe->info.platform == XE_DG2) {
> if (channel == CHANNEL_PKG)
[Severity: Medium]
Will VRAM temperature sensors be exposed on XE_CRESCENTISLAND platforms?
When checking sysfs attribute visibility, is_temp_available() queries
xe_hwmon_get_reg() for REG_TEMP. Since xe_hwmon_get_reg() only has branches
for XE_BATTLEMAGE and XE_DG2, it returns an invalid register (XE_REG(0)) for
XE_CRESCENTISLAND platforms.
This causes is_temp_available() to unconditionally return false. Does this
code need a branch for XE_CRESCENTISLAND to return the correct VRAM
temperature registers?
[ ... ]
> @@ -786,6 +854,17 @@ static int xe_hwmon_pcode_read_thermal_info(struct xe_hwmon *hwmon)
> drm_dbg(&hwmon->xe->drm, "thermal config count 0x%x\n", config);
> hwmon->temp.count = REG_FIELD_GET(TEMP_MASK, config);
>
> + if (hwmon->xe->info.platform >= XE_CRESCENTISLAND) {
> + hwmon->temp.vram_count = REG_FIELD_GET(VRAM_COUNT_MASK, config);
> + if (hwmon->temp.vram_count > XE_MAX_VRAM_CHANNELS) {
> + drm_warn(&hwmon->xe->drm, "VRAM channel count %d exceeds max %d, clamping\n",
> + hwmon->temp.vram_count, XE_MAX_VRAM_CHANNELS);
> + hwmon->temp.vram_count = XE_MAX_VRAM_CHANNELS;
> + }
> + } else {
> + hwmon->temp.vram_count = BMG_MAX_VRAM_CHANNELS;
> + }
> +
> return ret;
> }
[Severity: Medium]
Will this silently hide all VRAM temperature sensors on Battlemage (BMG)
platforms if the thermal PCODE mailbox initialization fails?
If xe_hwmon_pcode_read_thermal_info() encounters a failure (such as an error
reading READ_THERMAL_LIMITS or READ_THERMAL_CONFIG earlier in the function),
it returns early. This skips the fallback assignment of hwmon->temp.vram_count
at the end of the function.
Because hwmon->temp.vram_count is 0-initialized, the in_range() check will
subsequently evaluate to false in xe_hwmon_get_reg(), returning an invalid
register and hiding the sensors. Previously, this path fell back to a
hardcoded MAX_VRAM_CHANNELS value, preserving visibility.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902175507.3910573-1-karthik.poosa@intel.com?part=2
next prev parent reply other threads:[~2026-09-02 18:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 17:55 [PATCH v2 0/5] drm/xe/hwmon: Update hwmon thermal mailbox handling Karthik Poosa
2026-09-02 17:55 ` [PATCH v2 1/5] drm/xe/hwmon: Detect unavailable temperature sensors Karthik Poosa
2026-09-02 17:55 ` [PATCH v2 2/5] drm/xe/hwmon: Use VRAM temperature sensor count from thermal config on CRI Karthik Poosa
2026-09-02 18:10 ` sashiko-bot [this message]
2026-09-10 10:42 ` Poosa, Karthik
2026-09-02 18:43 ` Rodrigo Vivi
2026-09-10 11:33 ` Poosa, Karthik
2026-09-02 17:55 ` [PATCH v2 3/5] drm/xe/hwmon: Correct group selection for memory controller temperature Karthik Poosa
2026-09-02 18:17 ` sashiko-bot
2026-09-10 17:00 ` Poosa, Karthik
2026-09-02 17:55 ` [PATCH v2 4/5] drm/xe/hwmon: Decode CRI temperature registers as IEEE-754 Karthik Poosa
2026-09-02 18:08 ` sashiko-bot
2026-09-10 17:05 ` Poosa, Karthik
2026-09-02 17:55 ` [PATCH v2 5/5] drm/xe/hwmon: Disable memory controller and PCIe temperatures on CRI Karthik Poosa
2026-09-02 18:07 ` sashiko-bot
2026-09-03 6:11 ` Poosa, Karthik
2026-09-02 18:28 ` ✓ CI.KUnit: success for drm/xe/hwmon: Update hwmon thermal mailbox handling (rev2) Patchwork
2026-09-02 19:22 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-09-03 9:37 ` ✗ Xe.CI.FULL: " 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=20260902181022.28C201F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=karthik.poosa@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.