All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Arnd Bergmann <arnd@kernel.org>, <michael.j.ruhl@intel.com>,
	<lucas.demarchi@intel.com>
Cc: "Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"David E. Box" <david.e.box@linux.intel.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Michael J. Ruhl" <michael.j.ruhl@intel.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Jani Nikula" <jani.nikula@intel.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Tejas Upadhyay" <tejas.upadhyay@intel.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/xe/vsec: enforce CONFIG_INTEL_VSEC dependency
Date: Tue, 17 Dec 2024 13:52:11 -0500	[thread overview]
Message-ID: <Z2HIW4c-S_IA9bWb@intel.com> (raw)
In-Reply-To: <20241217071852.2261858-1-arnd@kernel.org>

On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> When INTEL_VSEC is in a loadable module, XE cannot be built-in any more:
> 
> x86_64-linux-ld: vmlinux.o: in function `xe_vsec_init':
> (.text+0x19861bf): undefined reference to `intel_vsec_register'
> 
> This could be enforced using a 'depends on INTEL_VSEC || !INTEL_VSEC'
> style dependency to allow building with VSEC completely disabled.
> My impression here is that this was not actually intended, and that
> continuing to support that combination would lead to more build bugs.
> 
> Instead, make it a hard dependency as all other INTEL_VSEC users are,
> and remove the inline stub alternative. This leads to a dependency
> on CONFIG_X86_PLATFORM_DEVICES, so the 'select' has to be removed
> to avoid a circular dependency.
> 

I really don't want us to hard lock this X86 dependency here.
What if we add a new DRM_XE_DGFX_PMT_SUPPORT and that
depends on INTEL_VSEC ?

and our if statement changes to
if (IS_ENABLED(DRM_XE_DGFX_PMT_SUPPORT)

We could even leave this enabled by default, but at least
it is an easy path to someone willing to run experiments
without depending on X86 I believe...

Cc: Michael J. Ruhl <michael.j.ruhl@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>

> Fixes: 0c45e76fcc62 ("drm/xe/vsec: Support BMG devices")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/gpu/drm/xe/Kconfig | 2 +-
>  include/linux/intel_vsec.h | 7 -------
>  2 files changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
> index 6c5b665d9384..217b51468497 100644
> --- a/drivers/gpu/drm/xe/Kconfig
> +++ b/drivers/gpu/drm/xe/Kconfig
> @@ -2,6 +2,7 @@
>  config DRM_XE
>  	tristate "Intel Xe Graphics"
>  	depends on DRM && PCI && MMU && (m || (y && KUNIT=y))
> +	depends on INTEL_VSEC
>  	select INTERVAL_TREE
>  	# we need shmfs for the swappable backing store, and in particular
>  	# the shmem_readpage() which depends upon tmpfs
> @@ -28,7 +29,6 @@ config DRM_XE
>  	select INPUT if ACPI
>  	select ACPI_VIDEO if X86 && ACPI
>  	select ACPI_BUTTON if ACPI
> -	select X86_PLATFORM_DEVICES if X86 && ACPI
>  	select ACPI_WMI if X86 && ACPI
>  	select SYNC_FILE
>  	select IOSF_MBI
> diff --git a/include/linux/intel_vsec.h b/include/linux/intel_vsec.h
> index b94beab64610..f2d55e686476 100644
> --- a/include/linux/intel_vsec.h
> +++ b/include/linux/intel_vsec.h
> @@ -138,13 +138,6 @@ static inline struct intel_vsec_device *auxdev_to_ivdev(struct auxiliary_device
>  	return container_of(auxdev, struct intel_vsec_device, auxdev);
>  }
>  
> -#if IS_ENABLED(CONFIG_INTEL_VSEC)
>  void intel_vsec_register(struct pci_dev *pdev,
>  			 struct intel_vsec_platform_info *info);
> -#else
> -static inline void intel_vsec_register(struct pci_dev *pdev,
> -				       struct intel_vsec_platform_info *info)
> -{
> -}
> -#endif
>  #endif
> -- 
> 2.39.5
> 

  parent reply	other threads:[~2024-12-17 18:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-17  7:18 [PATCH] drm/xe/vsec: enforce CONFIG_INTEL_VSEC dependency Arnd Bergmann
2024-12-17  8:00 ` ✗ CI.Patch_applied: failure for " Patchwork
2024-12-17 18:52 ` Rodrigo Vivi [this message]
2024-12-17 19:28   ` [PATCH] " Arnd Bergmann
2024-12-17 19:48     ` Rodrigo Vivi
2024-12-17 20:14     ` Lucas De Marchi
2024-12-17 20:39       ` Arnd Bergmann

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=Z2HIW4c-S_IA9bWb@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=airlied@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=david.e.box@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert+renesas@glider.be \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=michael.j.ruhl@intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tejas.upadhyay@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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.