[PATCH] platform/x86: Fix PCENGINES_APU2 Kconfig warning

[PATCH] platform/x86: Fix PCENGINES_APU2 Kconfig warning

[YueHaibing]

Fix Kconfig warning for PCENGINES_APU2 symbol:

WARNING: unmet direct dependencies detected for GPIO_AMD_FCH
  Depends on [n]: GPIOLIB [=n] && HAS_IOMEM [=y]
  Selected by [y]:
  - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]

WARNING: unmet direct dependencies detected for KEYBOARD_GPIO_POLLED
  Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && GPIOLIB [=n]
  Selected by [y]:
  - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]

Add GPIOLIB dependency to fix it.

Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/platform/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 8c8bd45..2409d26 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1322,7 +1322,7 @@ config HUAWEI_WMI
 
 config PCENGINES_APU2
 	tristate "PC Engines APUv2/3 front button and LEDs driver"
-	depends on INPUT && INPUT_KEYBOARD
+	depends on INPUT && INPUT_KEYBOARD && GPIOLIB
 	depends on LEDS_CLASS
 	select GPIO_AMD_FCH
 	select KEYBOARD_GPIO_POLLED
-- 
2.7.4

Re: [PATCH] platform/x86: Fix PCENGINES_APU2 Kconfig warning

[Enrico Weigelt, metux IT consult]

On 04.07.19 08:27, YueHaibing wrote:
> Fix Kconfig warning for PCENGINES_APU2 symbol:
> 
> WARNING: unmet direct dependencies detected for GPIO_AMD_FCH
>   Depends on [n]: GPIOLIB [=n] && HAS_IOMEM [=y]
>   Selected by [y]:
>   - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]
> 
> WARNING: unmet direct dependencies detected for KEYBOARD_GPIO_POLLED
>   Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && GPIOLIB [=n]
>   Selected by [y]:
>   - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]
> 
> Add GPIOLIB dependency to fix it.

hmm, I'm not really happy w/ the kernel config system at that point:

If the select on the gpio driver would just subsequently enable gpiolib,
everything would be fine. But that contradicts how subsystems are
currently handled - you first have to enable gpio subsystem before
choosing anything that depends on it :(

Could it make sense to refactor gpiolib in a way that pieces directly
needed by gpio consumers or drivers (hmm, perhaps have separate
dependency symbols for consumer vs driver) can be selected directly,
even if the big gpio subsystem knob is disabled ? (but the other things
like userland interfaces would remain disabled) ?

OTOH, for this particular patch:

Ack-By: Enrico Weigelt <info@metux.net>


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: [PATCH] platform/x86: Fix PCENGINES_APU2 Kconfig warning

[Andy Shevchenko]

On Mon, Jul 8, 2019 at 1:43 PM Enrico Weigelt, metux IT consult
<lkml@metux.net> wrote:
>
> On 04.07.19 08:27, YueHaibing wrote:
> > Fix Kconfig warning for PCENGINES_APU2 symbol:
> >
> > WARNING: unmet direct dependencies detected for GPIO_AMD_FCH
> >   Depends on [n]: GPIOLIB [=n] && HAS_IOMEM [=y]
> >   Selected by [y]:
> >   - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]
> >
> > WARNING: unmet direct dependencies detected for KEYBOARD_GPIO_POLLED
> >   Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && GPIOLIB [=n]
> >   Selected by [y]:
> >   - PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && INPUT [=y] && INPUT_KEYBOARD [=y] && LEDS_CLASS [=y]
> >
> > Add GPIOLIB dependency to fix it.
>

Applied.

> hmm, I'm not really happy w/ the kernel config system at that point:
>
> If the select on the gpio driver would just subsequently enable gpiolib,
> everything would be fine. But that contradicts how subsystems are
> currently handled - you first have to enable gpio subsystem before
> choosing anything that depends on it :(
>
> Could it make sense to refactor gpiolib in a way that pieces directly
> needed by gpio consumers or drivers (hmm, perhaps have separate
> dependency symbols for consumer vs driver) can be selected directly,
> even if the big gpio subsystem knob is disabled ? (but the other things
> like userland interfaces would remain disabled) ?
>
> OTOH, for this particular patch:
>

> Ack-By: Enrico Weigelt <info@metux.net>

Patchwork doesn't recognize non-standard tags, thus the patch went
without it to the upstream.

>
>
> --mtx
>
> --
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> info@metux.net -- +49-151-27565287



-- 
With Best Regards,
Andy Shevchenko