lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 14 Jul 2019 19:42:20 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc:     YueHaibing <yuehaibing@...wei.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH] platform/x86: Fix PCENGINES_APU2 Kconfig warning

On Mon, Jul 8, 2019 at 1:43 PM Enrico Weigelt, metux IT consult
<lkml@...ux.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@...ux.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@...ux.net -- +49-151-27565287



-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists