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. > >> > >> 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" I'd say bool "Enable PMT support for Intel DGFX" the X86 PMT sounds more the cpu package pmt which is enabled out of Xe scope hmm, I'm thinking we shouldn't also add depends on CONFIG_INTEL_PMT_TELEMETRY Dave, thoughts? Cc: David E. Box <david.e.box@xxxxxxxxxxxxxxx> > depends on DRM_XE && INTEL_VSEC > depends on DRM_XE=m || INTEL_VSEC=y > depends on X86 || COMPILE_TEST and also default y > > > > Arnd
