Re: [PATCH v3 2/3] ACPI: video: Remove CONFIG_X86 handling from nvidia_wmi_ec_supported()

[Armin Wolf <W_Armin@gmx.de>]

Am 18.09.26 um 15:03 schrieb Alex Deucher:

> On Fri, Sep 18, 2026 at 7:01 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> On Fri, 18 Sep 2026, Hans de Goede <hansg@kernel.org> wrote:
>>> Hi,
>>>
>>> On 16-Sep-26 09:16, Jani Nikula wrote:
>>>> On Wed, 16 Sep 2026, Armin Wolf <W_Armin@gmx.de> wrote:
>>>>> Am 15.09.26 um 14:31 schrieb Jani Nikula:
>>>>>
>>>>>> On Tue, 15 Sep 2026, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
>>>>>>> GPU people heads up!!
>>>>>>>
>>>>>>> On Wed, 2 Sep 2026, Armin Wolf wrote:
>>>>>>>
>>>>>>>> Am 01.09.26 um 23:30 schrieb Deucher, Alexander:
>>>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig
>>>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/Kconfig
>>>>>>>>>> index 12e4a41bf1f0..50305630f533 100644
>>>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig
>>>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
>>>>>>>>>> @@ -30,9 +30,7 @@ config DRM_AMDGPU
>>>>>>>>>>          # ACPI_VIDEO's dependencies must also be selected.
>>>>>>>>>>          select INPUT if ACPI
>>>>>>>>>>          select ACPI_VIDEO if ACPI
>>>>>>>>>> -     # On x86 ACPI_VIDEO also needs ACPI_WMI
>>>>>>>>>> -     select X86_PLATFORM_DEVICES if ACPI && X86
>>>>>>>>> The change below makes sense, but this one looks like it should remain
>>>>>>>>> unless X86_PLATFORM_DEVICES is handled some other way?
>>>>>>>>>
>>>>>>>>> Alex
>>>>>>>> AFAIK the dependency on X86_PLATFORM_DEVICES was only necessary because
>>>>>>>> ACPI-WMI depended on it in the past.
>>>>>>>> By now ACPI-WMI neither depends on X86_PLATFORM_DEVICES or X86 anymore.
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Could more GPU people besides Alex take a look on this. I'd want to make
>>>>>>> progress with this series within this cycle but would prefer to have Acks
>>>>>>> from GPU side.
>>>>>> I share the same concern with Alex. It seems to me we could now end up
>>>>>> with x86 configurations without X86_PLATFORM_DEVICES, which handle
>>>>>> e.g. backlight on a lot of platforms.
>>>>>>
>>>>>> I think the safer option might be to go for:
>>>>>>
>>>>>>     depends on X86_PLATFORM_DEVICES || !X86
>>>>>>
>>>>>> in all of the cases that select/depend on X86_PLATFORM_DEVICES in drm.
>>>>>>
>>>>>> The alternative is to find out, and handle the fallout, if any.
>>>>>>
>>>>>>
>>>>>> BR,
>>>>>> Jani.
>>>>> Alright, should i leave the original "select X86_PLATFORM_DEVICES if ..." statements
>>>>> as-is or should is change them to "depends on X86_PLATFORM_DEVICES || !X86" everywhere?
>>>> There are some places that depends on X86_PLATFORM_DEVICES. I think it's
>>>> almost always a mistake to have some places select and some places
>>>> depends on, and select should anyway be used with care. I'd go for
>>>> depends on.
>>> I'm a bit late to the party here, sorry.
>>>
>>> Note that X86_PLATFORM_DEVICES is an option which enables / disables
>>> a menu and does nothing more.
>>>
>>> Enabling it or depending on it by itself does nothing.
>>>
>>> The select used to be there since it must be selected to be able
>>> to select ACPI_WMI (which is no longer the case after this series).
>>>
>>> To depends on in XE was probably copy pasted from the existing
>>> select-s and then changed to a depends and already was a completely
>>> no-op since depending on ACPI_WMI was enough as that itself
>>> dependend on ACPI_WMI.
>>>
>>> As for X86_PLATFORM_DEVICES being needed for some backlight
>>> interfaces, depending on it by itself does not result in those
>>> interfaces being there. That requires enabling the actual drivers
>>> providing those interfaces.
>>>
>>> And I don't think that the GPU drivers should start depending
>>> on those since that will become very unyielding.
>>>
>>> TL;DR: I believe Armin's original patch is fine and this is
>>> a welcome cleanup / simplification of the DRM drivers Kconfig
>>> bits.
>> Your explanation makes sense, thanks.
> Yeah, sounds good.  Thanks!
>
> Alex

Nice, i suppose we can apply this series as-is then?

Thanks,
Armin Wolf

>> BR,
>> Jani.
>>
>>
>> --
>> Jani Nikula, Intel