From: sashiko-bot@kernel.org
To: "Mallesh Koujalagi" <mallesh.koujalagi@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v1 1/4] drm/xe/cper: Add KUnit tests for CPER GUID mappings
Date: Fri, 13 Nov 2026 12:17:46 +0000 [thread overview]
Message-ID: <sashiko-outbox-212753@kernel.org> (raw)
In-Reply-To: <20261113115827.1913629-7-mallesh.koujalagi@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] drm/xe/cper: xe_cper.c includes KUnit suite with IS_ENABLED
not IS_BUILTIN
- [Medium] drm/xe/cper: selecting UEFI_CPER without ACPI breaks x86
!CONFIG_ACPI build
--
commit e55c9c6f9e07f010c97ca750586d2e6ff80ae6be
Author: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
drm/xe/cper: Add KUnit tests for CPER GUID mappings
This commit adds KUnit tests in xe_cper_kunit.c to verify that CRI PCI IDs
and xe_device_guids[] entries stay in sync, and selects UEFI_CPER when
DRM_XE_KUNIT_TEST is enabled.
> diff --git a/drivers/gpu/drm/xe/Kconfig.debug b/drivers/gpu/drm/xe/Kconfig.debug
> index 79118d9efd93e..d7712460f2d52 100644
> --- a/drivers/gpu/drm/xe/Kconfig.debug
> +++ b/drivers/gpu/drm/xe/Kconfig.debug
> @@ -77,6 +77,7 @@ config DRM_XE_KUNIT_TEST
> tristate "KUnit tests for the drm xe driver" if !KUNIT_ALL_TESTS
> depends on DRM_XE && KUNIT && DEBUG_FS
> default KUNIT_ALL_TESTS
> + select UEFI_CPER if DRM_XE_KUNIT_TEST != n
[Severity: Medium]
Does selecting UEFI_CPER here without an ACPI dependency break x86 builds
when CONFIG_ACPI is disabled (such as with drivers/gpu/drm/xe/.kunitconfig)?
On x86, UEFI_CPER enables UEFI_CPER_X86, which compiles
drivers/firmware/efi/cper-x86.c. cper_print_proc_ia() calls
arch_apei_report_x86_error(), which is declared in <asm/acpi.h> and only
included by <linux/acpi.h> when CONFIG_ACPI is enabled, causing an
implicit declaration build failure when CONFIG_ACPI=n.
[ ... ]
> diff --git a/drivers/gpu/drm/xe/xe_cper.c b/drivers/gpu/drm/xe/xe_cper.c
> index bb90030bcd2d4..f19e64dd51664 100644
> --- a/drivers/gpu/drm/xe/xe_cper.c
> +++ b/drivers/gpu/drm/xe/xe_cper.c
> @@ -320,3 +320,7 @@ int xe_cper_sysfs_init(struct xe_device *xe)
> {
> return devm_device_add_group(xe->drm.dev, &cper_group);
> }
> +
> +#if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST)
> +#include "tests/xe_cper_kunit.c"
> +#endif
[Severity: Medium]
Should this guard use IS_BUILTIN(CONFIG_DRM_XE_KUNIT_TEST) instead of
IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST), matching other KUnit tests included
into core xe driver files (such as xe_log.c and xe_lmtt.c)?
xe_cper.o is linked into xe.ko rather than a separate test module, and
tests/xe_cper_kunit.c registers xe_cper_suite via kunit_test_suites().
When CONFIG_DRM_XE_KUNIT_TEST=m, IS_ENABLED() still compiles the suite
into xe.ko (or vmlinux if CONFIG_DRM_XE=y), so loading the driver runs
the KUnit suite immediately and taints the kernel with TAINT_TEST even
when no test module is loaded.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261113115827.1913629-6-mallesh.koujalagi@intel.com?part=1
next prev parent reply other threads:[~2026-11-13 12:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 11:58 [PATCH v1 0/4] Add KUnit tests for CPER GUID mappings Mallesh Koujalagi
2026-11-13 11:58 ` [PATCH v1 1/4] drm/xe/cper: " Mallesh Koujalagi
2026-11-13 12:17 ` sashiko-bot [this message]
2026-11-13 11:58 ` [PATCH v1 2/4] drm/xe/cper: Add KUnit tests for GUID uniqueness Mallesh Koujalagi
2026-11-13 11:58 ` [PATCH v1 3/4] drm/xe/cper: Validate platform GUIDs in KUnit tests Mallesh Koujalagi
2026-11-13 11:58 ` [PATCH v1 4/4] drm/xe/cper: Add PCI ID to GUID mapping verification in KUnit Mallesh Koujalagi
2026-11-13 12:07 ` ✗ CI.checkpatch: warning for Add KUnit tests for CPER GUID mappings Patchwork
2026-11-13 12:09 ` ✓ CI.KUnit: success " Patchwork
2026-11-13 12:25 ` ✗ CI.checksparse: warning " Patchwork
2026-11-13 12:42 ` ✓ Xe.CI.BAT: success " 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-212753@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@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.