From patchwork Fri Apr 29 08:24:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dirk Gouders X-Patchwork-Id: 8978331 Return-Path: X-Original-To: patchwork-linux-kbuild@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 82A6E9F46D for ; Fri, 29 Apr 2016 08:31:54 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 82248201C0 for ; Fri, 29 Apr 2016 08:31:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3BEE72021B for ; Fri, 29 Apr 2016 08:31:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752201AbcD2Ibm (ORCPT ); Fri, 29 Apr 2016 04:31:42 -0400 Received: from services.gouders.net ([141.101.32.176]:57516 "EHLO services.gouders.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752825AbcD2Ibj (ORCPT ); Fri, 29 Apr 2016 04:31:39 -0400 Received: from localhost ([193.175.198.193]) (authenticated bits=0) by services.gouders.net (8.14.8/8.14.8) with ESMTP id u3T8P4Qg019337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Apr 2016 10:25:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gouders.net; s=gnet; t=1461918305; bh=lPuyD9/hXI9IyKVN4BJ0ShVIbdc+6KnP2EvBl5+31V0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=fR+z2tv58eAfmTTyL0k10O81TQNxQ2WPUsfi7KgIBZk0e4z+doxdgIr3lemj6yAx8 upZk2riHIsf9tYliAfhiFfZIWwbNEJqZw5TYvH23umzE3VzfXn/aTTTHn+rvhHgdv0 vyjqt00aFJkHwv9rsQ1a3P59Id5qZJ9uDa+Mx8Ic= From: Dirk Gouders To: Michal Marek Cc: kbuild-all@01.org, Roger Quadros , Ruslan Bilovol , Bin Liu , Sebastian Andrzej Siewior , linux-kbuild@vger.kernel.org, USB list , Tomi Valkeinen Subject: [PATCH v5] kconfig/symbol.c: handle choice_values that depend on 'm' symbols In-Reply-To: <201604201924.7peNMcCF%fengguang.wu@intel.com> (kbuild test robot's message of "Wed, 20 Apr 2016 19:04:42 +0800") References: <201604201924.7peNMcCF%fengguang.wu@intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Fri, 29 Apr 2016 10:24:52 +0200 Message-ID: MIME-Version: 1.0 Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIM_ADSP_DISCARD, DKIM_SIGNED, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP If choices consist of choice_values of type tristate that depend on symbols set to 'm', those choice_values are not set to 'n' if the choice is changed from 'm' to 'y' (in which case only one active choice_value is allowed). Those values are also written to the config file causing modules to be built when they should not. The following config can be used to reproduce and examine the problem; with the frontend of your choice set "Choice 0" and "Choice 1" to 'm', then set "Tristate Choice" to 'y' and save the configuration: config modules boolean modules default y option modules config dependency tristate "Dependency" default m choice prompt "Tristate Choice" default choice0 config choice0 tristate "Choice 0" config choice1 tristate "Choice 1" depends on dependency endchoice This patch sets tristate choice_values' visibility that depend on symbols set to 'm' to 'n' if the corresponding choice is set to 'y'. This makes them disappear from the choice list and will also cause the choice_values' value set to 'n' in sym_calc_value() and as a result they are written as "not set" to the resulting .config file. Reported-by: Sebastian Andrzej Siewior Signed-off-by: Dirk Gouders Tested-by: Sebastian Andrzej Siewior Tested-by: Roger Quadros --- v5: This patch should handle tristate choice-values, only. I assumed that only tristate choice-values can have visibility 'm', which was wrong: tristate dependencies can result in 'm' visibility. So, add an explicit test if a symbol is of type tristate. I am a bit unsure how to handle Tested-By credits when patches change substantially and left the credits untouched but new test reports are welcome. --- scripts/kconfig/symbol.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c index 25cf0c2..2432298 100644 --- a/scripts/kconfig/symbol.c +++ b/scripts/kconfig/symbol.c @@ -209,12 +209,26 @@ static void sym_set_all_changed(void) static void sym_calc_visibility(struct symbol *sym) { struct property *prop; + struct symbol *choice_sym = NULL; tristate tri; /* any prompt visible? */ tri = no; + + if (sym_is_choice_value(sym)) + choice_sym = prop_get_symbol(sym_get_choice_prop(sym)); + for_all_prompts(sym, prop) { prop->visible.tri = expr_calc_value(prop->visible.expr); + /* + * Tristate choice_values with visibility 'mod' are + * not visible if the corresponding choice's value is + * 'yes'. + */ + if (choice_sym && sym->type == S_TRISTATE && + prop->visible.tri == mod && choice_sym->curr.tri == yes) + prop->visible.tri = no; + tri = EXPR_OR(tri, prop->visible.tri); } if (tri == mod && (sym->type != S_TRISTATE || modules_val == no))