Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941649AbcKQRqj (ORCPT ); Thu, 17 Nov 2016 12:46:39 -0500 Received: from mail-qt0-f172.google.com ([209.85.216.172]:36284 "EHLO mail-qt0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751652AbcKQRqg (ORCPT ); Thu, 17 Nov 2016 12:46:36 -0500 MIME-Version: 1.0 In-Reply-To: <1479383715.19539.53.camel@tiscali.nl> References: <1479373111.19539.24.camel@tiscali.nl> <20161117113301.qqce6a4kmmsv6ijl@tumbleweed> <1479383715.19539.53.camel@tiscali.nl> From: Valentin Rothberg Date: Thu, 17 Nov 2016 13:44:14 +0100 Message-ID: Subject: Re: i2c: undefined option I2C_ALGO_BUSCLEAR To: Paul Bolle Cc: smohammed@nvidia.com, treding@nvidia.com, Michal Marek , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1680 Lines: 45 Hi Paul, On Thu, Nov 17, 2016 at 12:55 PM, Paul Bolle 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