From patchwork Wed Apr 24 22:29:51 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Yann E. MORIN" X-Patchwork-Id: 2486751 Return-Path: X-Original-To: patchwork-linux-kbuild@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id DBEDC3FD85 for ; Wed, 24 Apr 2013 22:32:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758584Ab3DXWah (ORCPT ); Wed, 24 Apr 2013 18:30:37 -0400 Received: from mail-we0-f173.google.com ([74.125.82.173]:55555 "EHLO mail-we0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758537Ab3DXWa0 (ORCPT ); Wed, 24 Apr 2013 18:30:26 -0400 Received: by mail-we0-f173.google.com with SMTP id o7so1963217wea.4 for ; Wed, 24 Apr 2013 15:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:date:message-id:x-mailer :in-reply-to:references:in-reply-to:references; bh=M/cU0nvzRnafVwA2rT7K33c+ZFFGaRRzmF7kX44M0Zk=; b=i+p2cjblbyu0JIOd2jylVN9s0H1SK6ElCNYuOC4IhkaP17rDUSKKPXwSFxExD0p+M8 jICVQ36la6e9bLBKTZ6tOwzmfQ8GFGXskVPzuie+wD4ENRjkEWTOMpPXJ7q3sbaC5Z3e U/vhO8PleolsrpwkxJ2/Izvu/+oDJiJmGyDYm6ARDmL/tFJWZbee9AvOozLqAAZc+nuD RlFWhUYqoLsHbygaMJTAkjd1+5DIXzQBVx6ch1eAZxqZ2+fzfdyZrgE/0xZHzBl5pGbS TwveTsgdNxVlfUtAkZ/In2Cr2Wt46S4U0NFRfjNwh0WaRA/xqw/2oZ1ftnjXQfOPH3g8 KOTQ== X-Received: by 10.180.183.133 with SMTP id em5mr6704676wic.26.1366842624966; Wed, 24 Apr 2013 15:30:24 -0700 (PDT) Received: from gourin.bzh.lan (ks3095497.kimsufi.com. [94.23.60.27]) by mx.google.com with ESMTPSA id t14sm35982534wib.0.2013.04.24.15.30.23 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 15:30:24 -0700 (PDT) From: "Yann E. MORIN" To: linux-kbuild@vger.kernel.org Cc: Michal Marek , linux-kernel@vger.kernel.org, "Yann E. MORIN" Subject: [PATCH 4/8] kconfig: fix randconfig tristate detection Date: Thu, 25 Apr 2013 00:29:51 +0200 Message-Id: <61fa0e17f99b60b851d4480605b7d905d3172f0c.1366841993.git.yann.morin.1998@free.fr> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: References: In-Reply-To: References: Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org From: "Yann E. MORIN" Because the modules' symbole (CONFIG_MODULES) may not yet be set when we check a symbol's tristate capabilty, we'll always find that tristate symbols are booleans, even if we randomly decided that to enable modules: sym_get_type(sym) always return boolean for tristates when modules_sym has not been previously set to 'y' *and* its value calculated *and* its visibility calculated, both of which only occur after we randomly assign values to symbols. Fix that by looking at the raw type of symbols. Tristate set to 'm' will be promoted to 'y' when their values will be later calculated. Signed-off-by: "Yann E. MORIN" --- scripts/kconfig/confdata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index 13ddf11..306cbc1 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -1125,7 +1125,7 @@ void conf_set_all_new_symbols(enum conf_def_mode mode) sym->def[S_DEF_USER].tri = no; break; case def_random: - cnt = sym_get_type(sym) == S_TRISTATE ? 3 : 2; + cnt = sym->type == S_TRISTATE ? 3 : 2; sym->def[S_DEF_USER].tri = (tristate)(rand() % cnt); break; default: