Thread (22 messages) 22 messages, 7 authors, 2024-12-22

Re: [PATCH v2 1/3] fbdev: Fix recursive dependencies wrt BACKLIGHT_CLASS_DEVICE

From: Jani Nikula <jani.nikula@linux.intel.com>
Date: 2024-12-12 23:24:25
Also in: dri-devel, linux-fbdev, linux-staging

On Thu, 12 Dec 2024, "Arnd Bergmann" [off-list ref] wrote:
On Thu, Dec 12, 2024, at 19:44, Helge Deller wrote:
quoted
On 12/12/24 11:04, Thomas Zimmermann wrote:
quoted
Do not select BACKLIGHT_CLASS_DEVICE from FB_BACKLIGHT. The latter
only controls backlight support within fbdev core code and data
structures.

Make fbdev drivers depend on BACKLIGHT_CLASS_DEVICE and let users
select it explicitly. Fixes warnings about recursive dependencies,
such as [...]
I think in the fbdev drivers themselves you should do:
	select BACKLIGHT_CLASS_DEVICE
instead of "depending" on it.
This is the way as it's done in the DRM tiny and the i915/gma500 DRM drivers.

So, something like:
--- a/drivers/staging/fbtft/Kconfig
        tristate "Support for small TFT LCD display modules"
        depends on FB && SPI
        depends on FB_DEVICE
   +    select BACKLIGHT_DEVICE_CLASS
        depends on GPIOLIB || COMPILE_TEST
        select FB_BACKLIGHT
config FB_BACKLIGHT
           tristate
           depends on FB
   -	  select BACKLIGHT_CLASS_DEVICE
   +       depends on BACKLIGHT_CLASS_DEVICE


Would that fix the dependency warning?
The above is generally a mistake and the root cause of the
dependency loops. With very few exceptions, the solution in
these cases is to find the inconsistent 'select' and change
it into 'depends on'.
Agreed.
I actually have a few more patches like this that I've
been carrying for years now, e.g. one that changes all the
'select I2C' into appropriate dependencies.
I've done that for BACKLIGHT_CLASS_DEVICE and some related configs years
ago, but there was pushback, and I gave up. Nowadays when I see this I
just chuckle briefly and move on.

Occasionally I quote Documentation/kbuild/kconfig-language.rst:

	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

If kconfig warned about selecting symbols with dependencies it would be
painful for a while but eventually I think life would be easier.

BR,
Jani.


-- 
Jani Nikula, Intel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help