On Mon, Feb 12, 2024, at 15:31, Duje Mihanović wrote:

On Monday, February 12, 2024 1:44:28 PM CET Daniel Thompson wrote:

quoted

On Mon, Feb 12, 2024 at 12:18:12PM +0100, Arnd Bergmann wrote:

I believe this would be the best thing to do here. Making LEDS_EXPRESSWIRE 
user selectable doesn't make much sense to me as the library is rather low-
level (a quick grep turns up BTREE as an example of something similar) and IMO 
the GPIOLIB dependency should be handled by LEDS_EXPRESSWIRE as it's the one 
actually using the GPIO interface (except maybe for KTD2692 as it has some 
extra GPIOs not present in the other one and thus handles them itself).

Agree, let's do it this way. Maybe the leds-expresswire.c file should
not be in drivers/leds either, but it's already there and I can't think
of a better place for it.so just adapting Kconfig should be enough.

Please add the corresponding Makefile change as well though:

--- a/drivers/Makefile
+++ b/drivers/Makefile

@@ -135,7 +135,7 @@ obj-$(CONFIG_CPU_IDLE)              += cpuidle/
 obj-y                          += mmc/
 obj-y                          += ufs/
 obj-$(CONFIG_MEMSTICK)         += memstick/
-obj-$(CONFIG_NEW_LEDS)         += leds/
+obj-y                          += leds/
 obj-$(CONFIG_INFINIBAND)       += infiniband/
 obj-y                          += firmware/
 obj-$(CONFIG_CRYPTO)           += crypto/

Without this, the expresswire library module won't
get built unless NEW_LEDS is enabled.

     Arnd