On Mon, Feb 12, 2024, at 15:31, Duje Mihanović wrote:
> On Monday, February 12, 2024 1:44:28 PM CET Daniel Thompson wrote:
>> 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
