All of 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 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.