From: Raag Jadav <raag.jadav@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: "Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Arnd Bergmann" <arnd@kernel.org>,
"Matthew Brost" <matthew.brost@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Lucas De Marchi" <demarchi@kernel.org>,
"Riana Tauro" <riana.tauro@intel.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Matthew Auld" <matthew.auld@intel.com>,
"Shuicheng Lin" <shuicheng.lin@intel.com>,
"Armin Wolf" <W_Armin@gmx.de>,
"Zhanjun Dong" <zhanjun.dong@intel.com>,
"Michal Wajdeczko" <michal.wajdeczko@intel.com>,
"Piotr Piórkowski" <piotr.piorkowski@intel.com>,
"Tejas Upadhyay" <tejas.upadhyay@intel.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm: xe: select configfs
Date: Fri, 13 Nov 2026 18:51:36 +0100 [thread overview]
Message-ID: <avdOKFx63ZPNTTJ2@black.igk.intel.com> (raw)
In-Reply-To: <20261113162212.GB7214@mdroper-desk1>
On Fri, Nov 13, 2026 at 08:22:12AM -0800, Matt Roper wrote:
> On Wed, Nov 11, 2026 at 02:01:45PM -0500, Rodrigo Vivi wrote:
> > On Mon, Oct 26, 2026 at 11:25:50AM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > The original addition of configfs to xe missed a compile-time dependency,
> > > which leads to a link failure when configfs is enabled as a loadable module:
> > >
> > > ld.lld-21: error: undefined symbol: xe_configfs_get_survivability_mode
> > > >>> referenced by xe_survivability_mode.c:224
> > > >>> drivers/gpu/drm/xe/xe_survivability_mode.o:(xe_survivability_mode_is_requested) in archive vmlinux.a
> > >
> > > A recent workaround added a 'IS_REACHABLE()' check around the calls into
> > > configfs, which makes it link in this configuration, but this is generally
> > > a bad idea because it makes the actual behavior inconsistent and confusing
> > > to users that expect configfs to work if both xe and configfs are enabled.
> > >
> > > Use 'select CONFIGFS_FS' instead, like every other configfs user does,
> > > and remove the unnecessary stub functions. There is little practical
> > > difference here as anyone using XE graphics is likely to have a complex
> > > configuration that already selects configfs anyway, and the link error
> > > or the IS_REACHABLE() would only manifest during randconfig testing.
> > >
> > > Fixes: 30499cbd7961 ("drm/xe: Fix build with DRM_XE=y and CONFIGFS_FS=m")
> > > Fixes: 16280ded45fb ("drm/xe: Add configfs to enable survivability mode")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > drivers/gpu/drm/xe/Kconfig | 1 +
> > > drivers/gpu/drm/xe/xe_configfs.h | 30 ------------------------------
> > > 2 files changed, 1 insertion(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
> > > index 4fc8abdc5cb6..b52a8dc28f97 100644
> > > --- a/drivers/gpu/drm/xe/Kconfig
> > > +++ b/drivers/gpu/drm/xe/Kconfig
> > > @@ -11,6 +11,7 @@ config DRM_XE
> > > # the shmem_readpage() which depends upon tmpfs
> > > select SHMEM
> > > select TMPFS
> > > + select CONFIGFS_FS
> >
> > Perhaps another option would be what Jani had suggested:
> >
> > config DRM_XE_CONFIGFS
> > def_bool y
> > depends on DRM_XE && CONFIGFS_FS
> > depends on CONFIGFS_FS=y || DRM_XE=m
> >
> > But anyway, we are depending more and more on the configfs for
> > production choices. So, let's go with you select and close this
> > for good.
>
> I really don't think this patch was the way we wanted to go.
> IS_REACHABLE was giving us exactly the behavior that we wanted, but now
> we're getting behavior that we did not want. Xe absolutely does not
> depend on configfs in any way. _If_ configfs is there we'll enable some
> config options in it, but none of those are mandatory for our driver as
> a whole. We're perfectly happy to build and run without configfs if
> it's not selected in the config. We're also happy to build and run
> without configfs functionality if the user wanted Xe built directly into
> the kernel, but configfs was built as an unreachable module solely for
> other non-Xe purposes.
>
> While this change won't matter to 99% of the cases where someone is
> running with a typical distro kernel, this is the kind of thing that
> makes embedded users unhappy since they're very carefully managing their
> configurations and we've taken away their ability to avoid configfs now.
+1'ing on this. People go to great lengths to save a few bytes, only to
be undone by a non-essential config.
Raag
prev parent reply other threads:[~2026-11-13 17:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 10:25 Arnd Bergmann
2026-11-11 19:01 ` Rodrigo Vivi
2026-11-13 16:22 ` Matt Roper
2026-11-13 17:51 ` Raag Jadav [this message]
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=avdOKFx63ZPNTTJ2@black.igk.intel.com \
--to=raag.jadav@intel.com \
--cc=W_Armin@gmx.de \
--cc=airlied@gmail.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=demarchi@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=piotr.piorkowski@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=shuicheng.lin@intel.com \
--cc=simona@ffwll.ch \
--cc=tejas.upadhyay@intel.com \
--cc=thomas.hellstrom@linux.intel.com \
--cc=zhanjun.dong@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®