From patchwork Tue Jun 9 04:09:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chen-Yu Tsai X-Patchwork-Id: 11594367 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2488F14E3 for ; Tue, 9 Jun 2020 04:10:08 +0000 (UTC) Received: from web01.groups.io (web01.groups.io [66.175.222.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F0018207C3 for ; Tue, 9 Jun 2020 04:10:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=lists.cip-project.org header.i=@lists.cip-project.org header.b="aXBoZL5x" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0018207C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csie.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=bounce+64572+4784+4520428+8129116@lists.cip-project.org X-Received: by 127.0.0.2 with SMTP id K3ysYY4521763x47IYZLOIxZ; Mon, 08 Jun 2020 21:10:07 -0700 X-Received: from wens.tw (wens.tw [140.112.30.76]) by mx.groups.io with SMTP id smtpd.web11.95.1591675802793344843 for ; Mon, 08 Jun 2020 21:10:03 -0700 X-Received: by wens.tw (Postfix, from userid 1000) id 779BF60141; Tue, 9 Jun 2020 12:09:59 +0800 (CST) From: "Chen-Yu Tsai (Moxa)" To: nobuhiro1.iwamatsu@toshiba.co.jp, pavel@denx.de Cc: cip-dev@lists.cip-project.org, JohnsonCH.Chen@moxa.com Subject: [cip-dev] [PATCH 4.4.y-cip v3 14/14] cpufreq: cpufreq-dt: avoid uninitialized variable warnings: Date: Tue, 9 Jun 2020 12:09:26 +0800 Message-Id: <20200609040926.8910-15-wens@csie.org> In-Reply-To: <20200609040926.8910-1-wens@csie.org> References: <20200609040926.8910-1-wens@csie.org> MIME-Version: 1.0 Precedence: Bulk List-Unsubscribe: Sender: cip-dev@lists.cip-project.org List-Id: Mailing-List: list cip-dev@lists.cip-project.org; contact cip-dev+owner@lists.cip-project.org Delivered-To: mailing list cip-dev@lists.cip-project.org Reply-To: cip-dev@lists.cip-project.org X-Gm-Message-State: wahlS4ZkwkXcxAEN86j3GlADx4520428AA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.cip-project.org; q=dns/txt; s=20140610; t=1591675807; bh=mhqlQnDBYfwQQWzo5XkFWAoCipkGZD3ZTahupnsEhjc=; h=Cc:Content-Type:Date:From:Reply-To:Subject:To; b=aXBoZL5xrFuThORRi3HfGt4UEg/Tfi50DmdDpKuNJGTqmsE4G5vDyeysZ1SrywcvRJj yFMCIHOKuF///t7nbjtf3gl2D0xlF9XXXK2sgR0/bJZd+Snsdpy8vD+A0IBQOX03zfJ99 H9VMTgDiN26ktnL90AUSI59mdVyxS6q8yhI= From: Arnd Bergmann commit b331bc20d9281213f7fb67912638e0fb5baeb324 upstream. gcc warns quite a bit about values returned from allocate_resources() in cpufreq-dt.c: cpufreq-dt.c: In function 'cpufreq_init': cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here cpufreq-dt.c: In function 'dt_cpufreq_probe': cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here The problem is that it's slightly hard for gcc to follow return codes across PTR_ERR() calls. This patch uses explicit assignments to the "ret" variable to make it easier for gcc to verify that the code is actually correct, without the need to add a bogus initialization. Signed-off-by: Arnd Bergmann Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Chen-Yu Tsai (Moxa) --- drivers/cpufreq/cpufreq-dt.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index 9bc37c437874a..0ca74d0700583 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -142,15 +142,16 @@ static int allocate_resources(int cpu, struct device **cdev, try_again: cpu_reg = regulator_get_optional(cpu_dev, reg); - if (IS_ERR(cpu_reg)) { + ret = PTR_ERR_OR_ZERO(cpu_reg); + if (ret) { /* * If cpu's regulator supply node is present, but regulator is * not yet registered, we should try defering probe. */ - if (PTR_ERR(cpu_reg) == -EPROBE_DEFER) { + if (ret == -EPROBE_DEFER) { dev_dbg(cpu_dev, "cpu%d regulator not ready, retry\n", cpu); - return -EPROBE_DEFER; + return ret; } /* Try with "cpu-supply" */ @@ -159,18 +160,16 @@ try_again: goto try_again; } - dev_dbg(cpu_dev, "no regulator for cpu%d: %ld\n", - cpu, PTR_ERR(cpu_reg)); + dev_dbg(cpu_dev, "no regulator for cpu%d: %d\n", cpu, ret); } cpu_clk = clk_get(cpu_dev, NULL); - if (IS_ERR(cpu_clk)) { + ret = PTR_ERR_OR_ZERO(cpu_clk); + if (ret) { /* put regulator */ if (!IS_ERR(cpu_reg)) regulator_put(cpu_reg); - ret = PTR_ERR(cpu_clk); - /* * If cpu's clk node is present, but clock is not yet * registered, we should try defering probe.