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]

Message-ID: <54a7d035-155f-c47b-1db1-acb851b3aec6@metux.net>
Date:   Tue, 5 Mar 2019 14:50:33 +0100
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Arnd Bergmann <arnd@...db.de>
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>,
        yamada.masahiro@...ionext.com, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH 2/3] x86: apuv2: fix input dependencies

On 05.03.19 09:23, Arnd Bergmann wrote:

(CC'ing kbuild maintainer + list, hoping for better ideas :)

> 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.

Okay, I didn't consider the defaults.

Maybe we should talk about step by step getting away from these defaults
(perhaps move them to the defconfigs ?) on a broader scale ... but yeah,
that's far out of scope now.

So, you've conviced me.
Add me to Reviewed-By to your patches and forget about mine.

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

hmm, if circular deps happen, wouldn't that mean we've got some deeper
problems in here ? IMHO, dependencies should always form a DAG (except
for some really rare cases).

Do you recall any actual problem w/ input vs gpio vs. drivers ?
I'd like to have a closer look at it.

> 1. try to use 'depends on' if you can

Well, this has the unpleasant side effect that we often have to enable
a lot of things, just to even see the individual driver. For people who
just wanna configure a kernel for their board, this is a bit nasty.

But, okay, I'm going to do this w/ my own tool - I've written a small
tool that allows easy kernel reconfiguration on a higher level: you
can just pick some board templates and enable high level features like
eth, gpu, etc - it automatically creates a .config for you. I'm going
announce it on lkml soon.

--mtx

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