[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <ea049651-32c5-42d7-96a0-fc236680a714@app.fastmail.com>
Date: Fri, 30 Jun 2023 13:34:21 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Javier Martinez Canillas" <javierm@...hat.com>,
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
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
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.
>>> 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.
Arnd
Powered by blists - more mailing lists