From: Karol Herbst <kherbst@redhat.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lyude Paul <lyude@redhat.com>, Ben Skeggs <bskeggs@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
Daniel Vetter <daniel@ffwll.ch>,
ML nouveau <nouveau@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] nouveau: make backlight support non optional
Date: Sat, 24 Jul 2021 14:10:53 +0200 [thread overview]
Message-ID: <CACO55tsoi2akTKvFdz3p48UHRjFXDW7dUnOM8qVePBFWet-3UQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a1BceSaiqkTf+9Pr4Br-G3kgqD4ztwiaS7fxNiUg9t7Dg@mail.gmail.com>
On Sat, Jul 24, 2021 at 1:56 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Sat, Jul 24, 2021 at 11:55 AM Karol Herbst <kherbst@redhat.com> wrote:
> >
> > On Sat, Jul 24, 2021 at 8:55 AM Arnd Bergmann <arnd@kernel.org> wrote:
> > >
> > > On Sat, Jul 24, 2021 at 12:47 AM Karol Herbst <kherbst@redhat.com> wrote:
> > > >
> > > > In the past this only led to compilation issues. Also the small amount of
> > > > extra .text shouldn't really matter compared to the entire nouveau driver
> > > > anyway.
> > > >
> > >
> > > > select DRM_TTM_HELPER
> > > > - select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT
> > > > - select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT
> > > > + select BACKLIGHT_CLASS_DEVICE
> > > > + select ACPI_VIDEO if ACPI && X86 && INPUT
> > > > select X86_PLATFORM_DEVICES if ACPI && X86
> > > > select ACPI_WMI if ACPI && X86
> > >
> > > I think the logic needs to be the reverse: instead of 'select
> > > BACKLIGHT_CLASS_DEVICE',
> > > this should be 'depends on BACKLIGHT_CLASS_DEVICE', and the same for ACPI_VIDEO.
> > >
> > > We may want to add 'default DRM || FB' to BACKLIGHT_CLASS_DEVICE in the
> > > process so we don't lose it for users doing 'make oldconfig' or 'make defconfig'
> > >
> >
> > I think the problem with
> > "depends" is that the user needs to enable backlight support first
> > before even seeing nouveau and I don't know if that makes sense. But
> > maybe "default" is indeed helping here in this case.
>
> In general, no driver should ever 'select' a subsystem. Otherwise you end up
> with two problems:
>
> - enabling this one driver suddenly makes all other drivers that have
> a dependency
> on this visible, and some of those might have a 'default y', so you
> end up with
> a ton of stuff in the kernel that would otherwise not be there.
>
> - It becomes impossible to turn it off as long as some driver has that 'select'.
> This is the pretty much the same problem as the one you describe, just
> the other side of it.
>
> - You run into dependency loops that prevent a successful build when some
> other driver has a 'depends on'. Preventing these loops was the main
> reason I said we should do this change.
>
> In theory we could change the other 85 drivers that use 'depends on' today,
> and make BACKLIGHT_CLASS_DEVICE a hidden symbol that only ever
> selected by the drivers that need it. This would avoid the third problem but
> not the other one.
>
> Arnd
>
I see. Yeah, I guess we can do it this way then. I just wasn't aware
of the bigger picture here. Thanks for explaining.
next prev parent reply other threads:[~2021-07-24 12:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-23 22:46 [PATCH] nouveau: make backlight support non optional Karol Herbst
2021-07-24 6:55 ` Arnd Bergmann
2021-07-24 9:54 ` Karol Herbst
2021-07-24 11:56 ` Arnd Bergmann
2021-07-24 12:10 ` Karol Herbst [this message]
2021-07-24 12:51 ` Karol Herbst
2021-07-24 14:04 ` Arnd Bergmann
2021-07-24 14:13 ` Karol Herbst
2021-07-24 14:58 ` Arnd Bergmann
2021-08-04 14:10 ` [PATCH] depend on BACKLIGHT_CLASS_DEVICE for more devices Karol Herbst
2021-08-04 14:19 ` Arnd Bergmann
2021-08-04 14:43 ` Karol Herbst
2021-08-04 18:59 ` Karol Herbst
2021-08-04 21:09 ` Arnd Bergmann
2021-08-04 22:01 ` Karol Herbst
2021-08-05 6:50 ` Arnd Bergmann
2021-08-09 13:20 ` [PATCH] nouveau: make backlight support non optional Jani Nikula
2021-08-09 13:30 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACO55tsoi2akTKvFdz3p48UHRjFXDW7dUnOM8qVePBFWet-3UQ@mail.gmail.com \
--to=kherbst@redhat.com \
--cc=arnd@kernel.org \
--cc=bskeggs@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).