linux-kernel - Re: [PATCH 1/2] fbdev: Split frame buffer support in FB and 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]

Date:   Fri, 30 Jun 2023 14:22:04 +0200
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Borislav Petkov <bp@...en8.de>,
        Daniel Vetter <daniel@...ll.ch>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "H. Peter Anvin" <hpa@...or.com>, Helge Deller <deller@....de>,
        Ingo Molnar <mingo@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
        x86@...nel.org
Subject: Re: [PATCH 1/2] fbdev: Split frame buffer support in FB and FB_CORE
 symbols

"Arnd Bergmann" <arnd@...db.de> writes:

> On Fri, Jun 30, 2023, at 12:51, Javier Martinez Canillas wrote:
>> "Arnd Bergmann" <arnd@...db.de> writes:
>>
>>>> @@ -59,7 +71,7 @@ config FIRMWARE_EDID
>>>> 
>>>>  config FB_DEVICE
>>>>  	bool "Provide legacy /dev/fb* device"
>>>> -	depends on FB
>>>> +	depends on FB_CORE
>>>>  	default y
>>>>  	help
>>>>  	  Say Y here if you want the legacy /dev/fb* device file and
>>>
>>> I don't see this symbol in linux-next yet, what tree are you using
>>> as a base?
>>>
>>
>> It's now in the drm-misc/drm-misc-next branch [1]. It's not in -next yet
>> because it just landed a few days ago [2].
>>
>> [1]: https://cgit.freedesktop.org/drm/drm-misc/log/?h=drm-misc-next
>> [2]: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=701d2054fa3
>>
>> In fact, that's the reason why I rebased my previous attempt [0].
>
> Ok.
>
> I wonder if it would make sense to also make FB_DEVICE depend on FB
> instead of FB_CORE then. I don't think there is any actual dependency

No, because that wouldn't allow to have /dev/fb* devices when using the
DRM fbdev emulation layer. It could be the case that users have an old
fbdev user-space but the platform only has a DRM driver, in that case we
want to disable all native fbdev drivers (CONFIG_FB not set) but still
have FB_CORE, FB_DEVICE and DRM_FBDEV_EMULATION options enabled.

> between the two, but as I understand we want modern distros to use
> neither FB nor FB_DEVICE, so tying them together with a dependency
> may be desirable anyway.
>

As said, modern distros would want to disable both FB and FB_DEVICE, but
we want to allow for these two options to be {en,dis}abled independently.

>
>>>>  config FB_BACKLIGHT
>>>>  	tristate
>>>> -	depends on FB
>>>> +	depends on FB_CORE
>>>>  	select BACKLIGHT_CLASS_DEVICE
>>>
>>> Separating this one from FB_CORE would help avoid circular dependencies,
>>> this one keeps causing issues.
>>>
>>
>> You mean separating from FB or should I keep the existing depends on FB?
>>
>> It seems this is only used by fbdev drivers so probably the latter?
>
> Right, I meant keeping the dependency on FB. Ideally we'd
> turn this all into a set of 'depends on' instead of 'select',
> but that is a completely separate topic.
>

Ok.

>     Arnd
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat