On Tue, Dec 17, 2024 at 08:28:59PM +0100, Arnd Bergmann wrote:
On Tue, Dec 17, 2024, at 19:52, Rodrigo Vivi wrote:
On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
From: Arnd Bergmann <arnd@xxxxxxxx>
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.
why? if xe is built-in, vsec needs to be built-in as well. If xe is a
module, vsec can be either built-in or a module.
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 ?
Yes, that should work if it gets phrased correctly.
Something like
config DRM_XE_DGFX_PMT_SUPPORT
bool "X86 PMT support"
depends on DRM_XE && INTEL_VSEC
depends on DRM_XE=m || INTEL_VSEC=y
depends on X86 || COMPILE_TEST
that looks good to me.
thanks
Lucas De Marchi
