linux-kernel - Re: i2c: undefined option I2C_ALGO

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 17 Nov 2016 13:44:14 +0100
From:   Valentin Rothberg <valentinrothberg@...il.com>
To:     Paul Bolle <pebolle@...cali.nl>
Cc:     smohammed@...dia.com, treding@...dia.com,
        Michal Marek <mmarek@...e.cz>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: i2c: undefined option I2C_ALGO_BUSCLEAR

Hi Paul,

On Thu, Nov 17, 2016 at 12:55 PM, Paul Bolle <pebolle@...cali.nl> wrote:
> Hi Valentin,
>
> On Thu, 2016-11-17 at 12:33 +0100, Valentin Rothberg wrote:
>> I tested your patch and it works properly for me.  It even still applies
>> on linux-next.
>
> Cool.
>
> (We should probably compile a list of current invalid selects somewhere
> publicly, and team up to submit patches for the low hanging fruit (ie, obvious
> typos) and for the arches that actually matter before I resubmit.)

Sounds like a plan.   At the moment I really don't have much time, but
starting in mid December I could help.  I propose to generate a bunch
of (rand)configs for different arches and collect the warnings with
your patch.  After we just need to compare it with the symbols from
checkkconfigsymbols.

>> Would it be possible to extend your patch to also check
>> symbols in other statements (depends on, if, etc.)?
>
> No. Depending on an unknown symbol is common and correct. Think
>     depends on SOME_OBSCURE_ARM_BOARD
>
> somewhere in drivers. Only arm builds will ever know about the
> SOME_OBSCURE_ARM_BOARD symbol.

You're completely right, thanks.  Obviously I was too lazy to think about it.

> What could be done is starting any "make *config" target with a treewide pass
> over all Kconfig files to collect all valid symbols and so spot typos and
> other obviously incorrect. The example that comes to mind is
>     depends on SH
>
> that I have spotted a few times in the past years. But this treewide pass will
> incur some runtime cost and might not be easy to implement cleanly. Perhaps
> we're better of with using your script for that.

I agree.

Kind regards,
 Valentin