[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2d6ab8ab-79c8-681b-a898-a88b48fceb55@redhat.com>
Date: Fri, 14 Jan 2022 09:31:55 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
Felipe Balbi <balbi@...nel.org>
Cc: Jarrett Schultz <jaschultzms@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Mark Gross <markgross@...nel.org>,
Maximilian Luz <luzmaximilian@...il.com>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
platform-driver-x86@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Jarrett Schultz <jaschultz@...rosoft.com>
Subject: Re: [PATCH 2/5] platform: surface: Propagate ACPI Dependency
Hi,
On 1/14/22 09:29, Geert Uytterhoeven wrote:
> Hi Felipe,
>
> On Fri, Jan 14, 2022 at 7:21 AM Felipe Balbi <balbi@...nel.org> wrote:
>> Geert Uytterhoeven <geert@...ux-m68k.org> writes:
>>> On Mon, Dec 6, 2021 at 4:03 PM Jarrett Schultz <jaschultzms@...il.com> wrote:
>>>> Since the Surface XBL Driver does not depend on ACPI, the
>>>> platform/surface directory as a whole no longer depends on ACPI. With
>>>> respect to this, the ACPI dependency is moved into each config that depends
>>>> on ACPI individually.
>>>>
>>>> Signed-off-by: Jarrett Schultz <jaschultz@...rosoft.com>
>>>
>>> Thanks for your patch, which is now commit 272479928172edf0 ("platform:
>>> surface: Propagate ACPI Dependency").
>>>
>>>> --- a/drivers/platform/surface/Kconfig
>>>> +++ b/drivers/platform/surface/Kconfig
>>>> @@ -5,7 +5,6 @@
>>>>
>>>> menuconfig SURFACE_PLATFORMS
>>>> bool "Microsoft Surface Platform-Specific Device Drivers"
>>>> - depends on ACPI
>>>> default y
>>>> help
>>>> Say Y here to get to see options for platform-specific device drivers
>>>
>>> Without any dependency, all users configuring a kernel are now asked
>>> about this. Is there any other platform dependency that can be used
>>> instead?
>>
>> there's probably no symbol that would be true for x86 and arm64 while
>> being false for everything else. Any ideas?
>
> depends on ARM64 || X86 || COMPILE_TEST?
That sounds reasonable to me, I would be happy to take a patch for that.
Regards,
Hans
Powered by blists - more mailing lists