All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Raag Jadav" <raag.jadav@intel.com>, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v5 5/5] drm/xe/ras: Move xe_ras_process_errors() to xe_ras
Date: Tue, 13 Oct 2026 11:22:21 +0000	[thread overview]
Message-ID: <sashiko-outbox-169612@kernel.org> (raw)
In-Reply-To: <20261013110439.181447-6-raag.jadav@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] xe_ras: boot-time wedge uevents are dropped before device registration
--

commit 7cc17054a629b3feb51763fdbe477fcbb6bc6ef3
Author: Raag Jadav <raag.jadav@intel.com>

drm/xe/ras: Move xe_ras_process_errors() to xe_ras

This commit moves xe_ras_process_errors() from the end of the probe
sequence back to xe_ras_init(). This was done to revert a previous change
and process hardware errors detected before the driver was loaded.

> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 23dfff89a4aa0..8d23e9cac3c67 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
[ ... ]
> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
> index 922e5e793b135..8e399ffec9856 100644
> --- a/drivers/gpu/drm/xe/xe_ras.c
> +++ b/drivers/gpu/drm/xe/xe_ras.c
[ ... ]
> @@ -932,6 +932,13 @@ void xe_ras_init(struct xe_device *xe)
>  	if (IS_ENABLED(CONFIG_PCIEAER))
>  		ras_usp_aer_init(xe);
>  
> +	/*
> +	 * During probe, process and log any errors detected by firmware while the driver was not
> +	 * loaded. Critical errors such as Punit and CSC are reported through Pcode init failure,
> +	 * causing the driver to enter survivability mode.
> +	 */
> +	xe_ras_process_errors(xe);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Medium]
Will this silently drop boot-time wedge uevents?

Moving xe_ras_process_errors() to xe_ras_init() causes it to execute before
drm_dev_register() is called in the probe sequence.

If a hardware error is detected during early probe, xe_wedge_declare() in
drivers/gpu/drm/xe/xe_wedge.c will broadcast a wedge event to userspace:

drivers/gpu/drm/xe/xe_wedge.c:xe_wedge_declare()
  drivers/gpu/drm/drm_drv.c:drm_dev_wedged_event()
    kobject_uevent_env()

Since the DRM device has not been added to sysfs yet, the KOBJ_CHANGE uevent
is silently dropped by the kobject core because dev->primary->kdev is not
fully registered. This means userspace automation will miss the WEDGED uevent.

> +
>  	ret = devm_device_add_group(xe->drm.dev, &gpu_health_group);
>  	if (ret)
>  		xe_err(xe, "Failed to create GPU health sysfs, err=%d\n", ret);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013110439.181447-1-raag.jadav@intel.com?part=5

  reply	other threads:[~2026-10-13 11:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13 11:03 [PATCH v5 0/5] Introduce xe_wedge Raag Jadav
2026-10-13 11:03 ` [PATCH v5 1/5] drm/xe/gt: Use GT ordered workqueue for wedging Raag Jadav
2026-10-13 11:19   ` sashiko-bot
2026-10-13 18:29   ` Rodrigo Vivi
2026-10-13 18:49     ` Matthew Brost
2026-10-13 11:03 ` [PATCH v5 2/5] drm/xe: Drop xe_device_set_wedged_method() Raag Jadav
2026-10-13 11:20   ` sashiko-bot
2026-10-13 18:30   ` Rodrigo Vivi
2026-10-13 11:03 ` [PATCH v5 3/5] drm/xe: Move xe_device_wedged_fini() registration to xe_device_probe_early() Raag Jadav
2026-10-13 11:03 ` [PATCH v5 4/5] drm/xe: Introduce xe_wedge Raag Jadav
2026-10-13 11:16   ` sashiko-bot
2026-10-13 18:32   ` Rodrigo Vivi
2026-10-13 11:03 ` [PATCH v5 5/5] drm/xe/ras: Move xe_ras_process_errors() to xe_ras Raag Jadav
2026-10-13 11:22   ` sashiko-bot [this message]
2026-10-13 11:12 ` ✗ CI.checkpatch: warning for Introduce xe_wedge (rev4) Patchwork
2026-10-13 11:14 ` ✓ CI.KUnit: success " Patchwork
2026-10-13 15:40 ` ✓ 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=sashiko-outbox-169612@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=raag.jadav@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.