linux-kernel - Re: [PATCH 2/3] x86: apuv2: fix input dependencies

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 5 Mar 2019 09:23:06 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc:     Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Linus Walleij <linusw@...nel.org>,
        Enrico Weigelt <info@...ux.net>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] x86: apuv2: fix input dependencies

On Tue, Mar 5, 2019 at 1:18 AM Enrico Weigelt, metux IT consult
<lkml@...ux.net> wrote:
>
> On 04.03.19 21:19, Arnd Bergmann wrote:
>
> > This could be fixed using either a dependency or a 'select' statement.
> > I'm chosen 'depends on' here since it is simpler has a lower risk of
> > introducing circular dependencies.
>
> I'd rather prefer using 'select'.
>
> Otherwise the driver won't appear at all if INPUT or INPUT_KEYBOARD
> aren't enabled (eg. when you start w/ minimal config - which I do
> frequently), and people have a hard time actually finding/enabling it.

No, that wouldn't be good here. In effect that means that with INPUT disabled,
most of the x86 platform drivers are disabled, until you enable the
PCENGINES_APU2 symbol, which then ends up showing all the other
symbols at once, and changing them to their default states.

Another problem is that you likely run into circular dependency chains
after trying that. The best practice for select vs. depends are

1. try to use 'depends on' if you can
2. use 'select' on hidden symbols, but not user visible ones
3. for each symbol, use either 'depends on'  or 'select' from all other
    drivers that need it, and do it consistently
4. never select entire subsystems, only helper code.

Those are sometimes at odds. I used 'select' for the LEDS code
because of 3. and 4, even though that goes against 2. For INPUT,
there is no real debate though.

   Arnd