[PATCH] drm/xe/vsec: fix CONFIG_INTEL_VSEC dependency

Andy Shevchenko andriy.shevchenko at linux.intel.com
Wed May 28 10:16:09 UTC 2025


On Wed, May 28, 2025 at 12:03:43PM +0200, Arnd Bergmann wrote:
> On Wed, May 28, 2025, at 11:34, Andy Shevchenko wrote:
> > On Tue, May 27, 2025 at 03:55:46PM -0500, Lucas De Marchi wrote:
> >> On Fri, May 23, 2025 at 02:10:46PM +0200, Arnd Bergmann wrote:
> >
> > ...
> >
> >> > +	depends on INTEL_PLATFORM_DEVICES || !(X86 && ACPI)
> >> 
> >> 		   ^
> >> Did you mean X86_PLATFORM_DEVICES here?
> 
> Yes, my mistake.
> 
> > Why do we need to depend on the whole thingy (yes, it will be enabled at the
> > end) if we only talking about Intel?
> 
> I don't understand what you mean with 'the whole thing'. My change
> changed the existing 'select X86_PLATFORM_DEVICES if X86 && ACPI'
> into the corresponding dependency, in order to change it the
> least.

It used to be (for only one or two releases) X86_PLATFORM_DRIVERS_INTEL, but it
doesn't look closer to the mistake above, which I was thinking of. So, Lucas is
right.

> The dependency itself is needed because of
> 
>        select ACPI_WMI if X86 && ACPI
> 
> and this in turn is needed for
> 
>        select ACPI_VIDEO if X86 && ACPI
> 
> >> With that, Reviewed-by: Lucas De Marchi <lucas.demarchi at intel.com>
> >> 
> >> I see several drivers selecting
> >> X86_PLATFORM_DEVICES though. Maybe they should also be translated to
> >> dependencies instead?
> >
> > I think so, selecting that sounds wrong.
> 
> Agreed. Overall, what I'd really like to see is to remove
> all those 'select' of drivers from other subsystems.

Let's start from some low-hanging fruits?

> I think
> ACPI_VIDEO is at the center here, and changing all the
> 'select ACPI_VIDEO if ACPI' instances to
> 'depends on ACPI_VIDEO || !ACPI_VIDEO' would solve a lot of
> the recurring dependency loop problems in drivers/gpu/.
> 
> Actually doing it without regressions is going to be
> nontrivial though, because any change in this area is likely
> to trigger another dependency loop somewhere.

True and I agree this requires more comprehensive testing.

-- 
With Best Regards,
Andy Shevchenko




More information about the dri-devel mailing list