On Monday, January 22, 2024 6:50:31 PM CET Daniel Thompson wrote:

On Mon, Jan 22, 2024 at 06:26:04PM +0100, Duje Mihanović wrote:

quoted

On Monday, January 22, 2024 5:57:53 PM CET Duje Mihanović wrote:

quoted

On Monday, January 22, 2024 5:50:11 PM CET Daniel Thompson wrote:

quoted

AFAICT nothing will inhibit setting GPIOLIB so allyes- and 

allmodconfig

quoted

quoted

quoted

builds will always end up with GPIOLIB enabled. If we are happy to
select it then I think that is enough!

In that case I guess I'll just make it select GPIOLIB.

Nevermind that, it'll have to be 'depends on' after all:

drivers/gpio/Kconfig:6:error: recursive dependency detected!
drivers/gpio/Kconfig:6: symbol GPIOLIB is selected by LEDS_EXPRESSWIRE
drivers/leds/Kconfig:184:       symbol LEDS_EXPRESSWIRE depends on 

NEW_LEDS

Can this dependency could be broken by declaring LEDS_EXPRESSWIRE at
the top (or bottom) of the KConfig file (it's an option without a UI
and does not need to be within the if NEW_LEDS block).

Nope, the only change is that the dependency graph is somewhat shorter:

drivers/gpio/Kconfig:6:error: recursive dependency detected!
drivers/gpio/Kconfig:6: symbol GPIOLIB is selected by LEDS_EXPRESSWIRE
drivers/leds/Kconfig:9: symbol LEDS_EXPRESSWIRE is selected by 
BACKLIGHT_KTD2801
drivers/video/backlight/Kconfig:186:    symbol BACKLIGHT_KTD2801 depends on 
BACKLIGHT_CLASS_DEVICE
drivers/video/backlight/Kconfig:136:    symbol BACKLIGHT_CLASS_DEVICE is 
selected by FB_BACKLIGHT
drivers/video/fbdev/core/Kconfig:180:   symbol FB_BACKLIGHT is selected by 
FB_SSD1307
drivers/video/fbdev/Kconfig:1934:       symbol FB_SSD1307 depends on GPIOLIB
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"

Regards,
--
Duje