linux-kernel - Re: [PATCH v2 2/2] drm: Make fbdev emulation select FB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sfa6aa85.fsf@minerva.mail-host-address-is-not-set>
Date:   Sun, 02 Jul 2023 12:17:30 +0200
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>
Cc:     linux-kernel@...r.kernel.org,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Daniel Vetter <daniel@...ll.ch>,
        Dave Airlie <airlied@...il.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 2/2] drm: Make fbdev emulation select FB_CORE instead
 of depends on FB

Geert Uytterhoeven <geert@...ux-m68k.org> writes:

> Hi Arnd,
>
> On Sun, Jul 2, 2023 at 12:07 AM Arnd Bergmann <arnd@...db.de> wrote:
>> On Sat, Jul 1, 2023, at 23:44, Javier Martinez Canillas wrote:
>> > Now that the fbdev core has been split in FB_CORE and FB, make DRM fbdev
>> > emulation layer to just select the former.
>> >
>> > This allows to disable the CONFIG_FB option if is not needed, which will
>> > avoid the need to explicitly disable each of the legacy fbdev drivers.
>> >
>> > Signed-off-by: Javier Martinez Canillas <javierm@...hat.com>
>> > ---
>> >
>> > Changes in v2:
>> > - Make CONFIG_DRM_FBDEV_EMULATION to select FB_CORE (Thomas Zimmermann).
>> >
>> >  drivers/gpu/drm/Kconfig | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> > index afb3b2f5f425..d9b1710e3ad0 100644
>> > --- a/drivers/gpu/drm/Kconfig
>> > +++ b/drivers/gpu/drm/Kconfig
>> > @@ -132,7 +132,7 @@ config DRM_DEBUG_MODESET_LOCK
>> >  config DRM_FBDEV_EMULATION
>> >       bool "Enable legacy fbdev support for your modesetting driver"
>> >       depends on DRM_KMS_HELPER
>> > -     depends on FB=y || FB=DRM_KMS_HELPER
>> > +     select FB_CORE
>>
>> This will unfortunately force FB_CORE=y even with DRM=m, it would be nice
>> to allow both to be loadable modules. Any of these should work:
>>

Right, I missed that. Thanks for pointing that out.

>> a) Add another hidden symbol like
>>
>> config DRM_FB_CORE
>>       def_tristate DRM && DRM_FBDEV_EMULATION
>>       select FB_CORE
>
> More complexity to keep track of...
>

Yes, I would avoid this option as well.

>>
>> b) move the 'select' to DRM
>>
>> config DRM
>>       tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"
>>       select FB_CORE if DRM_FBDEV_EMULATION
>
> I prefer this one, as it keeps the select close to the user.
>

Agreed with Geert that this is the best option.

> BTW, the tristate help text can use some overhaul ;-)
>

Indeed :) I will add a preparatory patch to this series improving that
prompt text.

>> c) Remove the 'select' and instead use the default
>>
>> config FB_CORE
>>      def_tristate FB || (DRM && DRM_FBDEV_EMULATION)
>
> Adding it here means this patch would touch two subsystems.
>

Yeah. Even when in practice we push changes for drivers/video and
drivers/gpu/drm in drm-misc, I agree that option (b) is better.

> Gr{oetje,eeting}s,
>
>                         Geert
>
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat