From: sashiko-bot@kernel.org
To: "Umesh Nerlige Ramappa" <umesh.nerlige.ramappa@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v4 3/7] drm/xe/guc: Make ct_dead_capture available on non-debug config
Date: Fri, 18 Sep 2026 00:06:16 +0000 [thread overview]
Message-ID: <20260918000616.AACED1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260917235923.1521112-12-umesh.nerlige.ramappa@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] build: xe_guc_ct compile error on !CONFIG_DRM_XE_DEBUG
--
commit 1f4499efdc2f257f0698c2212dc79db666b74590
Author: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
drm/xe/guc: Make ct_dead_capture available on non-debug config
Define ct_dead_capture for non-debug as well to simplify future
refactor.
> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
> index b3a6aa37808b4..3353515aa8747 100644
> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
> @@ -59,6 +59,9 @@ static struct xe_device *ct_to_xe(struct xe_guc_ct *ct)
> return gt_to_xe(ct_to_gt(ct));
> }
>
> +#define ct_id(reason_code) CT_DEAD_##reason_code
> +#define CT_DEAD(ct, ctb, reason_code) ct_dead_capture((ct), (ctb), ct_id(reason_code))
> +
> #if IS_ENABLED(CONFIG_DRM_XE_DEBUG)
> enum {
> /* Internal states, not error conditions */
[Severity: Low]
Will this break compilation for non-debug builds?
The macro CT_DEAD now unconditionally references CT_DEAD_##reason_code, but
the enumeration defining these reason codes remains strictly guarded by
#if IS_ENABLED(CONFIG_DRM_XE_DEBUG) just below.
Any invocation of CT_DEAD in common code could cause an undeclared identifier
error when CONFIG_DRM_XE_DEBUG is disabled.
[ ... ]
> @@ -2376,4 +2369,10 @@ static void ct_dead_worker_func(struct work_struct *w)
>
> spin_unlock_irq(&ct->dead.lock);
> }
> +#else
> +static void ct_dead_capture(struct xe_guc_ct *ct, struct guc_ctb *ctb, u32 reason_code)
> +{
> + if (ctb)
> + ctb->info.broken = true;
> +}
> #endif
[Severity: Low]
Does ct_dead_capture() also need a forward declaration for the non-debug
path?
Since this non-debug implementation is defined at the end of the file with
no preceding forward declaration, calling CT_DEAD() earlier in the file may
result in an implicit function declaration error.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260917235923.1521112-9-umesh.nerlige.ramappa@intel.com?part=3
next prev parent reply other threads:[~2026-09-18 0:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 23:59 [PATCH v4 0/7] Use SIG_ID logs for GuC component Umesh Nerlige Ramappa
2026-09-17 23:59 ` [PATCH v4 1/7] drm/xe/guc: Use different error codes for GuC load errors Umesh Nerlige Ramappa
2026-09-17 23:59 ` [PATCH v4 2/7] drm/xe/guc: Handle CRASH and EXCEPTION G2H with separate helpers Umesh Nerlige Ramappa
2026-09-18 0:08 ` sashiko-bot
2026-09-17 23:59 ` [PATCH v4 3/7] drm/xe/guc: Make ct_dead_capture available on non-debug config Umesh Nerlige Ramappa
2026-09-18 0:06 ` sashiko-bot [this message]
2026-09-17 23:59 ` [PATCH v4 4/7] drm/xe/guc: Cleanup error codes and handling for CT errors Umesh Nerlige Ramappa
2026-09-18 0:17 ` sashiko-bot
2026-09-17 23:59 ` [PATCH v4 5/7] drm/xe/uc: Report DMA failure using SIGID Umesh Nerlige Ramappa
2026-09-18 0:07 ` sashiko-bot
2026-09-17 23:59 ` [PATCH v4 6/7] drm/xe/guc: Report major GuC failures " Umesh Nerlige Ramappa
2026-09-17 23:59 ` [PATCH v4 7/7] drm/xe/guc: Report errors that cause a CT shutdown " Umesh Nerlige Ramappa
2026-09-18 0:08 ` sashiko-bot
2026-09-18 0:58 ` ✗ CI.KUnit: failure for Use SIG_ID logs for GuC component (rev3) 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=20260918000616.AACED1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=umesh.nerlige.ramappa@intel.com \
/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.