Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Riana Tauro <riana.tauro@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-xe@lists.freedesktop.org, anshuman.gupta@intel.com,
	matthew.d.roper@intel.com
Subject: Re: [PATCH] drm/xe: select CONFIGFS_FS dependency
Date: Fri, 02 Jan 2026 17:13:07 +0200	[thread overview]
Message-ID: <58dca887809c8b87a137762225ccd2c43a74cdd8@intel.com> (raw)
In-Reply-To: <af33cc10-3b5e-44a3-8a51-8e5ae71091cc@intel.com>

On Fri, 02 Jan 2026, Riana Tauro <riana.tauro@intel.com> wrote:
> On 12/22/2025 6:12 PM, Jani Nikula wrote:
>> On Fri, 19 Dec 2025, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>>> On Fri, Dec 19, 2025 at 01:35:14PM +0530, Riana Tauro wrote:
>>>> Xe driver uses configfs functions to expose configuration to userspace.
>>>> If CONFIGFS_FS is built as module (=m) when Xe is built-in (=y),
>>>> undefined reference errors occur.
>>>
>>> Perhaps we don't need  this middle phrase. Only the first and the last.
>>> But anyway, we need the patch in. I just pushed it.
>> 
>> I think the correct fix to this one would've been
>> 
>> 	depends on CONFIGFS_FS || CONFIGFS_FS=n
>> 
>
> I tried this but it causes Kconfig recursive dependencies because some 
> configs select CONFIGFS_FS
>
> error: recursive dependency detected!
>          symbol DRM_XE depends on CONFIGFS_FS
>          symbol CONFIGFS_FS is selected by NET_9P_USBG
>          symbol NET_9P_USBG depends on USB_GADGET
>          symbol USB_GADGET is selected by USB_EHCI_TEGRA
>          symbol USB_EHCI_TEGRA depends on USB
>          symbol USB is selected by MOUSE_APPLETOUCH
>          symbol MOUSE_APPLETOUCH depends on INPUT
>          symbol INPUT is selected by DRM_XE

Yeah, it's the same old thing over and over and over and over again. A
symbol should really only be either selected or depended on, and only
non-visible symbols with no dependencies should be selected.

Documentation/kbuild/kconfig-language.rst:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

DRM_XE also shouldn't select INPUT, and we have that because it's a hack
to work around other selects:

drivers/gpu/drm/xe/Kconfig:

	# xe depends on ACPI_VIDEO when ACPI is enabled
	# but for select to work, need to select ACPI_VIDEO's dependencies, ick

Then people work around the issues by throwing more selects around
everywhere, making the mess even harder to untangle.


BR,
Jani.


>
>
> Thanks
> Riana
>
>> BR,
>> Jani.
>> 
>>>
>>> Thanks,
>>> Rodrigo.
>>>
>>>> Add select CONFIGFS_FS to ensure configfs is built at minimum required
>>>> level.
>>>>
>>>> Cc: Matt Roper <matthew.d.roper@intel.com>
>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>> Closes: https://lore.kernel.org/oe-kbuild-all/202512190827.IeXYj4qg-lkp@intel.com/
>>>> Closes: https://lore.kernel.org/oe-kbuild-all/202512181854.hPyTAXc5-lkp@intel.com/
>>>> Closes: https://lore.kernel.org/oe-kbuild-all/202512190407.CcUFXX2F-lkp@intel.com/
>>>> Fixes: 16280ded45fb ("drm/xe: Add configfs to enable survivability mode")
>>>> Signed-off-by: Riana Tauro <riana.tauro@intel.com>
>>>> ---
>>>>   drivers/gpu/drm/xe/Kconfig | 1 +
>>>>   1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
>>>> index 4b288eb3f5b0..1094c5fc5bdf 100644
>>>> --- a/drivers/gpu/drm/xe/Kconfig
>>>> +++ b/drivers/gpu/drm/xe/Kconfig
>>>> @@ -46,6 +46,7 @@ config DRM_XE
>>>>   	select WANT_DEV_COREDUMP
>>>>   	select AUXILIARY_BUS
>>>>   	select REGMAP if I2C
>>>> +	select CONFIGFS_FS
>>>>   	help
>>>>   	  Driver for Intel Xe2 series GPUs and later. Experimental support
>>>>   	  for Xe series is also available.
>>>> -- 
>>>> 2.47.1
>>>>
>> 
>

-- 
Jani Nikula, Intel

  reply	other threads:[~2026-01-02 15:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-19  8:05 [PATCH] drm/xe: select CONFIGFS_FS dependency Riana Tauro
2025-12-19  8:26 ` ✓ CI.KUnit: success for " Patchwork
2025-12-19  9:00 ` ✓ Xe.CI.BAT: " Patchwork
2025-12-19 16:04 ` [PATCH] " Rodrigo Vivi
2025-12-19 16:32   ` Matt Roper
2025-12-19 16:42     ` Michal Wajdeczko
2025-12-19 16:53       ` Matt Roper
2025-12-19 17:00       ` Vivi, Rodrigo
2025-12-21 10:48       ` Riana Tauro
2025-12-22 15:10         ` Rodrigo Vivi
2025-12-22 12:42   ` Jani Nikula
2026-01-02 14:57     ` Riana Tauro
2026-01-02 15:13       ` Jani Nikula [this message]
2025-12-20 10:07 ` ✗ Xe.CI.Full: failure for " 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=58dca887809c8b87a137762225ccd2c43a74cdd8@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.d.roper@intel.com \
    --cc=riana.tauro@intel.com \
    --cc=rodrigo.vivi@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