From: sashiko-bot@kernel.org
To: "Dnyaneshwar Bhadane" <dnyaneshwar.bhadane@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 03/12] drm/xe/hwmon: Report errors using structured xe_log API
Date: Wed, 19 Aug 2026 19:23:20 +0000 [thread overview]
Message-ID: <20260819192320.5D05B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260819191442.1957986-4-dnyaneshwar.bhadane@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `xe_log_err()` API is invoked with a hardcoded `-EIO` error value instead of the actual error code, corrupting structured telemetry.
- [Low] Missing newline character in the format string for `xe_log_err()` will cause malformed dmesg output.
--
--- Patch [3]: [PATCH 03/12] drm/xe/hwmon: Report errors using structured xe_log API ---
commit d3f9f82c222b6fd15cd76563436ef83288bc6453
Author: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
drm/xe/hwmon: Report errors using structured xe_log API
Replace drm_err() calls with xe_log_err() using the HWMON component
tag to enable structured error reporting with SIGID for hardware
monitor failures:
> diff --git a/drivers/gpu/drm/xe/xe_hwmon.c b/drivers/gpu/drm/xe/xe_hwmon.c
> index 5284cab6703d8..9ff351e87e5a2 100644
> --- a/drivers/gpu/drm/xe/xe_hwmon.c
> +++ b/drivers/gpu/drm/xe/xe_hwmon.c
[ ... ]
> @@ -563,9 +564,9 @@ xe_hwmon_power_max_interval_show(struct device *dev, struct device_attribute *at
> if (hwmon->xe->info.has_mbx_power_limits) {
> ret = xe_hwmon_pcode_read_power_limit(hwmon, power_attr, channel, ®_val);
> if (ret) {
> - drm_err(&hwmon->xe->drm,
> - "power interval read fail, ch %d, attr %d, val 0x%08x, ret %d\n",
> - channel, power_attr, reg_val, ret);
> + xe_log_err(hwmon->xe, HWMON, -EIO,
> + "power interval read fail, ch %d, attr %d, val 0x%08x, ret %d\n",
> + channel, power_attr, reg_val, ret);
[Severity: Medium]
In xe_hwmon_power_max_interval_show(), should we be passing the actual ret
error code instead of hardcoding -EIO here? By passing -EIO, the structured
error payload will log an incorrect telemetry value instead of the actual
failure code from xe_hwmon_pcode_read_power_limit() when it fails.
> reg_val = 0;
> }
> } else {
[ ... ]
> @@ -1599,7 +1600,8 @@ int xe_hwmon_register(struct xe_device *xe)
> &hwmon_chip_info,
> hwmon_groups);
> if (IS_ERR(hwmon->hwmon_dev)) {
> - drm_err(&xe->drm, "Failed to register xe hwmon (%pe)\n", hwmon->hwmon_dev);
> + xe_log_err(xe, HWMON, -EIO,
> + "Failed to register xe hwmon (%pe)", hwmon->hwmon_dev);
[Severity: Medium]
In xe_hwmon_register(), should this use PTR_ERR(hwmon->hwmon_dev) instead
of hardcoded -EIO to ensure the correct error is captured in telemetry when
devm_hwmon_device_register_with_info() fails?
[Severity: Low]
It looks like the \n terminator was accidentally dropped from the format
string during the conversion in xe_hwmon_register(). Since xe_log_err()
maps to dev_printk(), will this missing newline cause subsequent kernel
messages to be appended to the same line when hwmon registration fails?
> xe->hwmon = NULL;
> return PTR_ERR(hwmon->hwmon_dev);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260819191442.1957986-1-dnyaneshwar.bhadane@intel.com?part=3
next prev parent reply other threads:[~2026-08-19 19:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 19:14 [PATCH 00/12] drm/xe: Convert IO_BUS errors to structured xe_log API Dnyaneshwar Bhadane
2026-08-19 19:14 ` [PATCH 01/12] drm/xe/log: Add VRAM, PAT, and HWMON DRIVER_HARDWARE components Dnyaneshwar Bhadane
2026-08-19 19:14 ` [PATCH 02/12] drm/xe/ggtt: Report GGTT errors using structured logging Dnyaneshwar Bhadane
2026-08-19 19:14 ` [PATCH 03/12] drm/xe/hwmon: Report errors using structured xe_log API Dnyaneshwar Bhadane
2026-08-19 19:23 ` sashiko-bot [this message]
2026-08-19 19:14 ` [PATCH 04/12] drm/xe/mmio: Report BAR mapping " Dnyaneshwar Bhadane
2026-08-19 19:14 ` [PATCH 05/12] drm/xe/memirq: Report " Dnyaneshwar Bhadane
2026-08-19 19:22 ` sashiko-bot
2026-08-19 19:14 ` [PATCH 06/12] drm/xe/reg_whitelist: Report whitelist overflow " Dnyaneshwar Bhadane
2026-08-19 19:22 ` sashiko-bot
2026-08-19 19:14 ` [PATCH 07/12] drm/xe/reg_sr: Report save-restore errors " Dnyaneshwar Bhadane
2026-08-19 19:14 ` [PATCH 08/12] drm/xe/pat: Assert pat.ops before dereferencing members Dnyaneshwar Bhadane
2026-08-19 19:22 ` sashiko-bot
2026-08-19 19:14 ` [PATCH 09/12] drm/xe/pat: Report missing PAT table using structured xe_log API Dnyaneshwar Bhadane
2026-08-19 19:23 ` sashiko-bot
2026-08-19 19:14 ` [PATCH 10/12] drm/xe/pci: Report unknown GMDID versions " Dnyaneshwar Bhadane
2026-08-19 19:27 ` sashiko-bot
2026-08-19 19:14 ` [PATCH 11/12] drm/xe/lmtt: Report invalidation errors " Dnyaneshwar Bhadane
2026-08-19 19:28 ` sashiko-bot
2026-08-19 19:14 ` [PATCH 12/12] drm/xe/vram: Report VRAM " Dnyaneshwar Bhadane
2026-08-19 19:29 ` sashiko-bot
2026-08-19 19:23 ` ✓ CI.KUnit: success for drm/xe: Convert IO_BUS errors to " Patchwork
2026-08-19 20:45 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-20 1:38 ` ✗ Xe.CI.FULL: failure " 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=20260819192320.5D05B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dnyaneshwar.bhadane@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).