From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>,
kernel test robot <lkp@intel.com>,
Matt Roper <matthew.d.roper@intel.com>,
Riana Tauro <riana.tauro@intel.com>
Subject: Re: [PATCH 2/2] drm/xe/configfs: Fix 'undefined reference to xe_configfs_...' errors
Date: Mon, 22 Dec 2025 14:03:55 -0500 [thread overview]
Message-ID: <aUmWGyJNfbBmFFlt@intel.com> (raw)
In-Reply-To: <20251222175006.9706-3-michal.wajdeczko@intel.com>
On Mon, Dec 22, 2025 at 06:50:06PM +0100, Michal Wajdeczko wrote:
> On configs where Xe is built-in (DRM_XE=y) but configfs is defined
> as a module (CONFIGFS=m), we were not enabling our configfs stubs,
> which might lead to the following build errors:
>
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_guc.o: in function `xe_guc_init_post_hwconfig':
> xe_guc.c:(.text+0x2f08): undefined reference to `xe_configfs_get_psmi_enabled'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_hw_engine.o: in function `xe_hw_engines_init_early':
> xe_hw_engine.c:(.text+0xedc): undefined reference to `xe_configfs_get_engines_allowed'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_lrc.o: in function `setup_configfs_post_ctx_restore_bb':
> xe_lrc.c:(.text+0xb30): undefined reference to `xe_configfs_get_ctx_restore_post_bb'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_lrc.o: in function `setup_configfs_mid_ctx_restore_bb':
> xe_lrc.c:(.text+0xbc0): undefined reference to `xe_configfs_get_ctx_restore_mid_bb'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_lrc.o: in function `xe_lrc_init':
> xe_lrc.c:(.text+0x32fc): undefined reference to `xe_configfs_get_ctx_restore_mid_bb'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_module.o:(.data.rel.ro+0x10): undefined reference to `xe_configfs_init'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_module.o:(.data.rel.ro+0x18): undefined reference to `xe_configfs_exit'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_pci.o: in function `xe_pci_probe':
> xe_pci.c:(.text+0x1514): undefined reference to `xe_configfs_check_device'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_psmi.o: in function `xe_psmi_debugfs_register':
> xe_psmi.c:(.text+0x508): undefined reference to `xe_configfs_get_psmi_enabled'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_psmi.o: in function `xe_psmi_init':
> xe_psmi.c:(.text+0x5c4): undefined reference to `xe_configfs_get_psmi_enabled'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_rtp.o: in function `xe_rtp_match_psmi_enabled':
> xe_rtp.c:(.text+0xba0): undefined reference to `xe_configfs_get_psmi_enabled'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_survivability_mode.o: in function `xe_survivability_mode_is_requested':
> xe_survivability_mode.c:(.text+0x434): undefined reference to `xe_configfs_get_survivability_mode'
> powerpc64-linux-ld: drivers/gpu/drm/xe/xe_sriov_pf.o: in function `xe_sriov_pf_readiness':
> xe_sriov_pf.c:(.text+0x2a0): undefined reference to `xe_configfs_get_max_vfs'
>
> Fix that by using IS_REACHABLE check instead of IS_ENABLED when
> deciding whether to stub variant or not.
>
> Fixes: 16280ded45fb ("drm/xe: Add configfs to enable survivability mode")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202512190407.CcUFXX2F-lkp@intel.com/
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Cc: Riana Tauro <riana.tauro@intel.com>
> ---
> drivers/gpu/drm/xe/xe_configfs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_configfs.h b/drivers/gpu/drm/xe/xe_configfs.h
> index 9998ec7c9956..ab75485b08b6 100644
> --- a/drivers/gpu/drm/xe/xe_configfs.h
> +++ b/drivers/gpu/drm/xe/xe_configfs.h
> @@ -12,7 +12,7 @@
>
> struct pci_dev;
>
> -#if IS_ENABLED(CONFIG_CONFIGFS_FS)
> +#if IS_REACHABLE(CONFIG_CONFIGFS_FS)
Well, I'm not 100% confident with this. And probably the Jani's suggestion is
the safest one.
But perhaps this is acceptable in this case, only because if
we are built-in (y), we are not able to use configfs at all anyway...
our configfs usage already depends on us as module...
> int xe_configfs_init(void);
> void xe_configfs_exit(void);
> void xe_configfs_check_device(struct pci_dev *pdev);
> --
> 2.47.1
>
next prev parent reply other threads:[~2025-12-22 19:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-22 17:50 [PATCH 0/2] drm/xe/configs: Fix build breaks Michal Wajdeczko
2025-12-22 17:50 ` [PATCH 1/2] drm/xe/configfs: Fix 'parameter name omitted' errors Michal Wajdeczko
2025-12-22 18:58 ` Rodrigo Vivi
2025-12-22 17:50 ` [PATCH 2/2] drm/xe/configfs: Fix 'undefined reference to xe_configfs_...' errors Michal Wajdeczko
2025-12-22 19:03 ` Rodrigo Vivi [this message]
2025-12-22 22:42 ` Matt Roper
2025-12-23 10:35 ` Jani Nikula
2025-12-22 23:48 ` ✗ CI.checkpatch: warning for drm/xe/configs: Fix build breaks Patchwork
2025-12-22 23:50 ` ✓ CI.KUnit: success " Patchwork
2025-12-23 0:37 ` ✓ Xe.CI.BAT: " Patchwork
2025-12-23 8:32 ` ✓ Xe.CI.Full: " 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=aUmWGyJNfbBmFFlt@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=lkp@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=riana.tauro@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.