From patchwork Wed Feb 3 14:02:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 61095 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp310459lbl; Wed, 3 Feb 2016 06:03:06 -0800 (PST) X-Received: by 10.98.71.147 with SMTP id p19mr2355557pfi.165.1454508185755; Wed, 03 Feb 2016 06:03:05 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id zk5si9469379pac.234.2016.02.03.06.03.05; Wed, 03 Feb 2016 06:03:05 -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; dkim=pass header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756202AbcBCOC5 (ORCPT + 30 others); Wed, 3 Feb 2016 09:02:57 -0500 Received: from mail-pa0-f45.google.com ([209.85.220.45]:35411 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755906AbcBCOCx (ORCPT ); Wed, 3 Feb 2016 09:02:53 -0500 Received: by mail-pa0-f45.google.com with SMTP id ho8so14058295pac.2 for ; Wed, 03 Feb 2016 06:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=Tx9LVCcj2OGkdzlVUerx18R7O/dX/ZlIaNKdSTJ5VNU=; b=dxQ+3qrdtC9VSVT74tslhPBotUN+DxbsK3wIRYDEQcx7eO3/NqLw3jtlrh6JZuSVhW v0uAoay2SljYjn+z1/MeiphPU0+YwZ363CthbND64QHTxCIr2/CWAJMajp6qOodBJiQC 1gAjHCOWYNPOXEUvOoEPhftjUaIrhIW902JQA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=Tx9LVCcj2OGkdzlVUerx18R7O/dX/ZlIaNKdSTJ5VNU=; b=R6LUutyLP31yd5WNue7jvfwbKOmykTfV3WcK/95M5TM7RU+s5lJdwxIQS8XFljMsHb ChRHbcbXjqZEi6xuSsaIpHSvnvqWom8cUaRJz3IO5peNaQzbZ3YUi/aCeJ/4LwEbybZ1 JK0iyc/5VRHeBYOVIlXDhvQy1yeFMokrngXHJ12BFY56kfphNYarAvXonZB2Im55F0ZR GR4qy4FI5OZ8vdKdJfrODQRAK4qCNRs9XoY3fddzQZZV7FP7t7ZXZMuNe+pEQXU9jRMM 9CUowdDMXvvm6G7nRnUjHwqseZzPzHzfvbdeYlJTr9E7HYJyjhNNSuUsiKEj2sBLXntX Ol4w== X-Gm-Message-State: AG10YOQOEQBIUQpMWyP1cV9bzy5PEUBhDY/rzQap4EkCdU1kpSuvzgghpOStYYzFZdP8gOnC X-Received: by 10.66.218.73 with SMTP id pe9mr2311886pac.91.1454508172583; Wed, 03 Feb 2016 06:02:52 -0800 (PST) Received: from localhost ([122.172.22.246]) by smtp.gmail.com with ESMTPSA id cq4sm10201491pad.28.2016.02.03.06.02.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2016 06:02:51 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , juri.lelli@arm.com Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, skannan@codeaurora.org, peterz@infradead.org, mturquette@baylibre.com, steve.muckle@linaro.org, vincent.guittot@linaro.org, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, linux-kernel@vger.kernel.org, Viresh Kumar Subject: [PATCH V2 7/7] cpufreq: Remove cpufreq_governor_lock Date: Wed, 3 Feb 2016 19:32:23 +0530 Message-Id: <75f5a53c38b1efcfe7dc496525b0e96b6343a93e.1454507872.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.7.0.79.gdc08a19 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We used to drop policy->rwsem just before calling __cpufreq_governor() in some cases earlier and so it was possible that __cpufreq_governor() runs concurrently via separate threads. In order to guarantee valid state transitions for governors, 'governor_enabled' was required to be protected using some locking and we created cpufreq_governor_lock for that. But now, __cpufreq_governor() is always called from within policy->rwsem held and so 'governor_enabled' is protected against races even without cpufreq_governor_lock. Get rid of the extra lock now. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 7 ------- 1 file changed, 7 deletions(-) -- 2.7.0.79.gdc08a19 diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 4fc3889ca7c9..7bc8a5ed97e5 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -102,7 +102,6 @@ static LIST_HEAD(cpufreq_governor_list); static struct cpufreq_driver *cpufreq_driver; static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data); static DEFINE_RWLOCK(cpufreq_driver_lock); -DEFINE_MUTEX(cpufreq_governor_lock); /* Flag to suspend/resume CPUFreq governors */ static bool cpufreq_suspended; @@ -1963,11 +1962,9 @@ static int __cpufreq_governor(struct cpufreq_policy *policy, pr_debug("%s: for CPU %u, event %u\n", __func__, policy->cpu, event); - mutex_lock(&cpufreq_governor_lock); if ((policy->governor_enabled && event == CPUFREQ_GOV_START) || (!policy->governor_enabled && (event == CPUFREQ_GOV_LIMITS || event == CPUFREQ_GOV_STOP))) { - mutex_unlock(&cpufreq_governor_lock); return -EBUSY; } @@ -1976,8 +1973,6 @@ static int __cpufreq_governor(struct cpufreq_policy *policy, else if (event == CPUFREQ_GOV_START) policy->governor_enabled = true; - mutex_unlock(&cpufreq_governor_lock); - ret = policy->governor->governor(policy, event); if (!ret) { @@ -1987,12 +1982,10 @@ static int __cpufreq_governor(struct cpufreq_policy *policy, policy->governor->initialized--; } else { /* Restore original values */ - mutex_lock(&cpufreq_governor_lock); if (event == CPUFREQ_GOV_STOP) policy->governor_enabled = true; else if (event == CPUFREQ_GOV_START) policy->governor_enabled = false; - mutex_unlock(&cpufreq_governor_lock); } if (((event == CPUFREQ_GOV_POLICY_INIT) && ret) ||