[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