From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B180C7618F for ; Mon, 15 Jul 2019 14:55:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 63A2F20868 for ; Mon, 15 Jul 2019 14:55:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563202538; bh=Mw8zLDtV9BRhHcQ8YsKWL1X90TkecEVO3fMbNuhtLBk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=vyB0OV0NkfAcOuU7KLLvWiSJiXCV7/w1wwVgfjuix95gKpjjG9I37cinDAGY6Iipf iLAXFC14M37aO5tBDkEQzRvdQZnVhIcgvqFBv8hfoe7BDY4meEPu+fsrJS8Y4bqzp+ tK5T0HvBLBWZghVsAjOnBL5Kac3+oFphQGsJUNGU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391032AbfGOOZ5 (ORCPT ); Mon, 15 Jul 2019 10:25:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:33392 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390757AbfGOOZ5 (ORCPT ); Mon, 15 Jul 2019 10:25:57 -0400 Received: from sasha-vm.mshome.net (unknown [73.61.17.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E445421849; Mon, 15 Jul 2019 14:25:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563200756; bh=Mw8zLDtV9BRhHcQ8YsKWL1X90TkecEVO3fMbNuhtLBk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QIk1MhyoFdO3J2mXzzyK3WFRCqxY/pbz5EP8xjowGmb3GQzlsXLiFPjdhV1yrLcr1 Lp+16Kc13mEIl1U2gWrLmU/yn+Mm4xyt1AbIPV599U/vtxH1Ql7AubLV6dADxOj38H bSGGR8nhMFoQMIyMKNFXBATTTXf8Ru2IRJkvSNBc= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Viresh Kumar , "Rafael J . Wysocki" , Sasha Levin , linux-pm@vger.kernel.org Subject: [PATCH AUTOSEL 4.19 123/158] cpufreq: Don't skip frequency validation for has_target() drivers Date: Mon, 15 Jul 2019 10:17:34 -0400 Message-Id: <20190715141809.8445-123-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190715141809.8445-1-sashal@kernel.org> References: <20190715141809.8445-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org From: Viresh Kumar [ Upstream commit 9801522840cc1073f8064b4c979b7b6995c74bca ] CPUFREQ_CONST_LOOPS was introduced in a very old commit from pre-2.6 kernel release by commit 6a4a93f9c0d5 ("[CPUFREQ] Fix 'out of sync' issue"). Basically, that commit does two things: - It adds the frequency verification code (which is quite similar to what we have today as well). - And it sets the CPUFREQ_CONST_LOOPS flag only for setpolicy drivers, rightly so based on the code we had then. The idea was to avoid frequency validation for setpolicy drivers as the cpufreq core doesn't know what frequency the hardware is running at and so no point in doing frequency verification. The problem happened when we started to use the same CPUFREQ_CONST_LOOPS flag for constant loops-per-jiffy thing as well and many has_target() drivers started using the same flag and unknowingly skipped the verification of frequency. There is no logical reason behind skipping frequency validation because of the presence of CPUFREQ_CONST_LOOPS flag otherwise. Fix this issue by skipping frequency validation only for setpolicy drivers and always doing it for has_target() drivers irrespective of the presence or absence of CPUFREQ_CONST_LOOPS flag. cpufreq_notify_transition() is only called for has_target() type driver and not for set_policy type, and the check is simply redundant. Remove it as well. Also remove () around freq comparison statement as they aren't required and checkpatch also warns for them. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- drivers/cpufreq/cpufreq.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index d3213594d1a7..80942ec34efd 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -321,12 +321,10 @@ static void cpufreq_notify_transition(struct cpufreq_policy *policy, * which is not equal to what the cpufreq core thinks is * "old frequency". */ - if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) { - if (policy->cur && (policy->cur != freqs->old)) { - pr_debug("Warning: CPU frequency is %u, cpufreq assumed %u kHz\n", - freqs->old, policy->cur); - freqs->old = policy->cur; - } + if (policy->cur && policy->cur != freqs->old) { + pr_debug("Warning: CPU frequency is %u, cpufreq assumed %u kHz\n", + freqs->old, policy->cur); + freqs->old = policy->cur; } for_each_cpu(freqs->cpu, policy->cpus) { @@ -1543,8 +1541,7 @@ static unsigned int __cpufreq_get(struct cpufreq_policy *policy) if (policy->fast_switch_enabled) return ret_freq; - if (ret_freq && policy->cur && - !(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) { + if (has_target() && ret_freq && policy->cur) { /* verify no discrepancy between actual and saved value exists */ if (unlikely(ret_freq != policy->cur)) { -- 2.20.1