From patchwork Tue Dec 8 21:52:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 105134 Delivered-To: patch@linaro.org Received: by 10.112.147.194 with SMTP id tm2csp295615lbb; Tue, 8 Dec 2015 13:53:26 -0800 (PST) X-Received: by 10.66.162.38 with SMTP id xx6mr3158398pab.57.1449611605992; Tue, 08 Dec 2015 13:53:25 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q143si7628570pfq.191.2015.12.08.13.53.25; Tue, 08 Dec 2015 13:53:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751343AbbLHVxY (ORCPT + 28 others); Tue, 8 Dec 2015 16:53:24 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:52742 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750769AbbLHVxW (ORCPT ); Tue, 8 Dec 2015 16:53:22 -0500 Received: from wuerfel.localnet ([134.3.118.24]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0M6alo-1aRNPp147Q-00wWMB; Tue, 08 Dec 2015 22:52:49 +0100 From: Arnd Bergmann To: linux-pm@vger.kernel.org Cc: "Rafael J. Wysocki" , Viresh Kumar , Stephen Warren , Thierry Reding , Alexandre Courbot , linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, broonie@kernel.org, Liam Girdwood Subject: [PATCH] cpufreq: tegra: add regulator dependency for T124 Date: Tue, 08 Dec 2015 22:52:45 +0100 Message-ID: <2194927.eV2s2QmZs0@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) MIME-Version: 1.0 X-Provags-ID: V03:K0:+wMoEJf6KlitdlyXqKoweOznbu7plT+VT0WevNSL8S61QoKxWAo LHWfDtrbJCxgAaKLKb1HOCvSIhAw/OZd/TuBdRoHYYw1zA6tw390R9ZhgCCEjH4bH+mP9vv sMX2WzydhbqoPpkF6tnPEbJi5VmN2ySyQ5XqljLdz2SdaAFW6m80VI68l+tqseBbsk4BRoV dpWIQS2eWqSlnjIou/wNw== X-UI-Out-Filterresults: notjunk:1; V01:K0:E1JHN/t+oe8=:je0FMEjvWepQRlenBXeef5 mnCG90iIH97vEYk8uDymK1RKOmbif4UE/6dr0wTXhq99ni+FWo4B77enP1OHvRoYq+XjXeABD 7VKtb5mLp6gkOUoMfG/8f++D2EzeKdYGGNRGVwd6J1O3CTzSoYY8dWPC3Kr7gURQv7YAWhr/X Ue0Enh4wynEgK75/iTi6ghtSK8mva7XYGeUSWckwgPWGUbXgg4k7EoslnTszdTIUEuGRlFezF iqh8f+OaZSes583VVBJ1hn3OAbMXtXkc6VhMUvme7BF51ofFMqFTt9/BwhQv3aNhofkU3Jk3+ lkbcBzJO8RTVEdwLRrVHxzNJr/KmnpdoUINmBGbE5wbtCSyU/PhYP9ZntkSvtuKMWYaX0I3ck 3foGzyWdGUgcVTnrvX2xgGF0cxRE5+8vQYaQtwobXH81ZR6lEaI1l8vWO7c6WUAucD/a/I/Fz Ejl+AsAKZV2tgJl6ogbvMNV1n4tjMHXrxw8I023Nct5Df139UZgVtsra3KGGillVdnOjg0f8v 4MMFBMWgHdXGnkyH55PYMQLark8mYxD4eC2BTg9lDYPVuo1EY0cdjIniDg43WeNJSx2fneBKF OSh8GA/VcWFuIp1YUILGExNevEG+zhSPm0mWMpSsfEWyzYm260zWhIon/3gyV6LgjijPvKNlP /oR7KFQQu1wnHVJgT/X8W8x+NMsK5qbwhkab8pD1jEjJr//85YU37mRlxLDyRYRnIYx2z4udn oXo1yX36A8EVrzXX Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This driver is the only one that calls regulator_sync_voltage(), but it can currently be built with CONFIG_REGULATOR disabled, producing this build error: drivers/cpufreq/tegra124-cpufreq.c: In function 'tegra124_cpu_switch_to_pllx': drivers/cpufreq/tegra124-cpufreq.c:68:2: error: implicit declaration of function 'regulator_sync_voltage' [-Werror=implicit-function-declaration] regulator_sync_voltage(priv->vdd_cpu_reg); My first attempt was to implement a helper for this function for regulator_sync_voltage, but Mark Brown explained: We don't do this for *all* regulator API functions - there's some where using them strongly suggests that there is actually a dependency on the regulator API. This does seem like it might be falling into the specialist category [...] Looking at the code I'm pretty unclear on what the authors think the use of _sync_voltage() is doing in the first place so it may be even better to just remove the call. It seems to have been included in the first commit so there's not changelog explaining things and there's no comment either. I'd *expect* it to be a noop as far as I can see. This adds the dependency to make the driver always build successfully or not be enabled at all. Alternatively, we could investigate if the driver should stop calling regulator_sync_voltage instead. Signed-off-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 235a1ba73d92..b1f8a73e5a94 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -226,7 +226,7 @@ config ARM_TEGRA20_CPUFREQ config ARM_TEGRA124_CPUFREQ tristate "Tegra124 CPUFreq support" - depends on ARCH_TEGRA && CPUFREQ_DT + depends on ARCH_TEGRA && CPUFREQ_DT && REGULATOR default y help This adds the CPUFreq driver support for Tegra124 SOCs.