[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWEh07zXZZesuY0sksXaa6ptDvv3Fv4UC1RDkf7_KUv8w@mail.gmail.com>
Date: Fri, 14 Jan 2022 09:29:46 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: 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>,
Hans de Goede <hdegoede@...hat.com>,
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 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?
> In any case, what's the problem of being asked about a new symbol? That
> happens all the time whenever new drivers are merged, right?
In se there is no problem with being asked about a new symbol.
The problem is the sheer number of symbols, and irrelevant questions
(e.g. this one, on !x86 and !arm64).
Time spent on adding proper dependencies is IMHO well-spent, as it
will save time for everyone who configures his own kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists