From: sashiko-bot@kernel.org
To: "Alan Previn" <alan.previn.teres.alexis@intel.com>,
intel-xe@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability
Date: Fri, 30 Oct 2026 17:24:38 +0000 [thread overview]
Message-ID: <sashiko-outbox-191334@kernel.org> (raw)
In-Reply-To: <20261030171738.674775-2-alan.previn.teres.alexis@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/xe: duplicate and false logs in xe_survivability_mode_is_requested()
--
commit ba1b85f1f1a898ddfee38c1e881310a987970b44
Author: Alan Previn <alan.previn.teres.alexis@intel.com>
drm/xe/survivability: broadcast dmesg when engaging survivability
This commit adds kernel log messages to xe_survivability_mode_is_requested()
when boot survivability mode is requested via configfs or when PCODE_SCRATCH(0)
reports a boot failure.
> diff --git a/drivers/gpu/drm/xe/xe_survivability_mode.c b/drivers/gpu/drm/xe/xe_survivability_mode.c
> index 45d44ebe288b4..3eebb69728c3f 100644
> --- a/drivers/gpu/drm/xe/xe_survivability_mode.c
> +++ b/drivers/gpu/drm/xe/xe_survivability_mode.c
> @@ -412,13 +412,19 @@ bool xe_survivability_mode_is_requested(struct xe_device *xe)
>
> survivability_mode = xe_configfs_get_survivability_mode(pdev);
> /* Enable survivability mode if set via configfs */
> - if (survivability_mode)
> + if (survivability_mode) {
> + xe_log_info(xe, SURVIVABILITY, "Boot mode requested.");
> return true;
> + }
>
> data = xe_mmio_read32(mmio, PCODE_SCRATCH(0));
> survivability->boot_status = REG_FIELD_GET(BOOT_STATUS, data);
>
> - return check_boot_failure(xe);
> + if (check_boot_failure(xe)) {
> + xe_log_err_fatal(pdev, SURVIVABILITY, 0, "Boot Mode enabled!\n");
> + return true;
> + }
> + return false;
> }
[Severity: Medium]
Does logging inside xe_survivability_mode_is_requested() cause duplicate and
premature messages in dmesg?
During probe, xe_device_probe_early() calls
xe_survivability_mode_is_requested() in the condition and then calls
xe_survivability_mode_boot_enable(), which calls
xe_survivability_mode_is_requested() a second time:
drivers/gpu/drm/xe/xe_device.c:xe_device_probe_early() {
...
err = xe_pcode_probe_early(xe);
if (err || xe_survivability_mode_is_requested(xe)) {
int save_err = err;
...
err = xe_survivability_mode_boot_enable(xe);
}
drivers/gpu/drm/xe/xe_survivability_mode.c:xe_survivability_mode_boot_enable() {
...
if (!xe_survivability_mode_is_requested(xe))
return 0;
}
When xe_pcode_probe_early() returns 0 (for example, when survivability mode is
enabled via configfs), xe_survivability_mode_is_requested() runs twice back to
back and emits the log message twice. Also, "Boot mode requested." is missing a
trailing newline.
For the check_boot_failure(xe) path, enable_boot_survivability_mode() already
logs the exact same message once boot survivability mode has actually been
initialized:
drivers/gpu/drm/xe/xe_survivability_mode.c:enable_boot_survivability_mode() {
...
if (check_boot_failure(xe))
xe_log_err_fatal(pdev, SURVIVABILITY, 0, "Boot Mode enabled!\n");
else
xe_log_info(pdev, SURVIVABILITY, "Boot Mode enabled!\n");
return 0;
failed:
xe_log_err_fatal(pdev, SURVIVABILITY, ret, "Failed to enable Boot Mode!\n");
survivability->mode = false;
return ret;
}
Logging "Boot Mode enabled!\n" inside xe_survivability_mode_is_requested() not
only duplicates the message in enable_boot_survivability_mode(), but also
reports that boot mode is enabled before initialization has happened. If
xe_survivability_mode_boot_enable() aborts with -ENXIO (when
survivability->version < 2 and boot_status is CRITICAL_FAILURE) or if
enable_boot_survivability_mode() fails in create_survivability_sysfs(),
xe_nvm_init(), or xe_i2c_probe(), dmesg will falsely report "Boot Mode
enabled!" before failing.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261030171738.674775-2-alan.previn.teres.alexis@intel.com?part=1
next prev parent reply other threads:[~2026-10-30 17:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 17:17 [PATCH 1/1] drm/xe/survivability: broadcast dmesg when engaging survivability Alan Previn
2026-10-30 17:24 ` sashiko-bot [this message]
2026-10-30 18:01 ` ✓ CI.KUnit: success for series starting with [1/1] " Patchwork
2026-10-30 18:36 ` ✓ Xe.CI.BAT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2026-10-23 17:36 [PATCH 1/1] " Alan Previn
2026-10-28 3:18 ` Raag Jadav
2026-10-28 21:01 ` Teres Alexis, Alan Previn
2026-10-29 4:48 ` Raag Jadav
2026-10-29 9:38 ` Tauro, Riana
2026-10-29 18:41 ` Teres Alexis, Alan Previn
2026-10-29 18:57 ` Teres Alexis, Alan Previn
2026-10-23 0:18 Alan Previn
2026-10-23 0:27 ` sashiko-bot
2026-10-23 16:43 ` Teres Alexis, Alan Previn
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=sashiko-outbox-191334@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alan.previn.teres.alexis@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--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 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.