Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2622943ybk; Mon, 18 May 2020 03:59:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPR/B/W/XZBNNiF+iCqLShWwxmgHqul4/jHdPHrufLwwdNJzbO3UTRwUDkMETZE2EvyJFQ X-Received: by 2002:a05:6402:1547:: with SMTP id p7mr12620311edx.31.1589799577512; Mon, 18 May 2020 03:59:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589799577; cv=none; d=google.com; s=arc-20160816; b=NH3E4T363GcerUgjvSFPcdGo5xZfPFDirTelB/62i/MUf4AabANIYj2Qq4fn4fKhY4 S85dpnLg2wsQbhChipWOc043MGXtneP6Hn05UhEc6lFF1fsWarOAoof5NrrmcNlzjJlh +/C80z0lZDKn/K7VHFoykY72i3pdhl/IOLypebIuX4HYD8rEmAraQpiVkjf3yOvHEZun YDnlqqiiQUkncYuKDe7toa57NjxBRTyG4dYN0DYfLLPMb8R0z5HzxlmeWARK7LfkkPKU dOsXhbsv/L4LlYrzKd3aXUHkIRx65mE0BTPuLRLFPzqEF51yhSV3n2nERFTxk42dZ7ir DjVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Mx/DkoT1Z9QT2rJ7XhAZ2Zd1PlxF8x+jE+hpU1VAhWI=; b=nmXiJX+pENrDqlwWP+a+bpOKVKlbXbgUzkpCbGgOXvodZg8oHQj121B5otx5HQeTe2 BEQNnrFd8bTVMpJIXGB0c/8MG/zVSIWrEaYWXrFjW4JDD8lU8vwdaNjoyDPED+DUu/SH JUcEaN5/SXsNjuDJZQzanuS/uMGuGNrKVJPCu5TgIPFnmwXl3rMIfhGhvV6MhZXVr1y6 YCgDWcCTFZFNFGlEjxL9VMv7HYShPlDTO4llRoBcyRbiNzSva35oBjzl3386rgQFqzVO WiWgnInyz8t/4/PYnaqb+BIU2bkGBtAauu3/kgonLPFtsZyS4T0uSVuqg+FKwguGOzkq CbRA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u11si5071691edb.94.2020.05.18.03.59.14; Mon, 18 May 2020 03:59:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726693AbgERK47 (ORCPT + 99 others); Mon, 18 May 2020 06:56:59 -0400 Received: from mail.baikalelectronics.com ([87.245.175.226]:46332 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726362AbgERK47 (ORCPT ); Mon, 18 May 2020 06:56:59 -0400 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id B18DC8030875; Mon, 18 May 2020 10:56:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at baikalelectronics.ru Received: from mail.baikalelectronics.ru ([127.0.0.1]) by localhost (mail.baikalelectronics.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50YAqZGe6GZM; Mon, 18 May 2020 13:56:53 +0300 (MSK) Date: Mon, 18 May 2020 13:56:49 +0300 From: Serge Semin To: "Rafael J. Wysocki" CC: Serge Semin , "Rafael J. Wysocki" , Viresh Kumar , "Rafael J. Wysocki" , Thomas Bogendoerfer , Ulf Hansson , Matthias Kaehlcke , Alexey Malahov , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , , "devicetree@vger.kernel.org" , Stable , Frederic Weisbecker , Ingo Molnar , Yue Hu , Linux PM , Linux Kernel Mailing List Subject: Re: [PATCH v2 20/20] cpufreq: Return zero on success in boost sw setting Message-ID: <20200518105649.gcv22l253lsuje7y@mobilestation> References: <20200306124807.3596F80307C2@mail.baikalelectronics.ru> <20200518102415.k4c5qglodij5ac6h@vireshk-i7> <20200518103102.t3a3g4uxeeuwsnix@mobilestation> <5284478.EF2IWm2iUs@kreacher> <20200518104602.mjh2p5iltf2x4wmq@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 18, 2020 at 12:51:15PM +0200, Rafael J. Wysocki wrote: > On Mon, May 18, 2020 at 12:46 PM Serge Semin > wrote: > > > > On Mon, May 18, 2020 at 12:41:19PM +0200, Rafael J. Wysocki wrote: > > > On Monday, May 18, 2020 12:31:02 PM CEST Serge Semin wrote: > > > > On Mon, May 18, 2020 at 03:54:15PM +0530, Viresh Kumar wrote: > > > > > On 18-05-20, 12:22, Rafael J. Wysocki wrote: > > > > > > On Monday, May 18, 2020 12:11:09 PM CEST Viresh Kumar wrote: > > > > > > > On 18-05-20, 11:53, Rafael J. Wysocki wrote: > > > > > > > > That said if you really only want it to return 0 on success, you may as well > > > > > > > > add a ret = 0; statement (with a comment explaining why it is needed) after > > > > > > > > the last break in the loop. > > > > > > > > > > > > > > That can be done as well, but will be a bit less efficient as the loop > > > > > > > will execute once for each policy, and so the statement will run > > > > > > > multiple times. Though it isn't going to add any significant latency > > > > > > > in the code. > > > > > > > > > > > > Right. > > > > > > > > > > > > However, the logic in this entire function looks somewhat less than > > > > > > straightforward to me, because it looks like it should return an > > > > > > error on the first policy without a frequency table (having a frequency > > > > > > table depends on the driver and that is the same for all policies, so it > > > > > > is pointless to iterate any further in that case). > > > > > > > > > > > > Also, the error should not be -EINVAL, because that means "invalid > > > > > > argument" which would be the state value. > > > > > > > > > > > > So I would do something like this: > > > > > > > > > > > > --- > > > > > > drivers/cpufreq/cpufreq.c | 11 ++++++----- > > > > > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > > > > > > > > > Index: linux-pm/drivers/cpufreq/cpufreq.c > > > > > > =================================================================== > > > > > > --- linux-pm.orig/drivers/cpufreq/cpufreq.c > > > > > > +++ linux-pm/drivers/cpufreq/cpufreq.c > > > > > > @@ -2535,26 +2535,27 @@ EXPORT_SYMBOL_GPL(cpufreq_update_limits) > > > > > > static int cpufreq_boost_set_sw(int state) > > > > > > { > > > > > > struct cpufreq_policy *policy; > > > > > > - int ret = -EINVAL; > > > > > > > > > > > > for_each_active_policy(policy) { > > > > > > + int ret; > > > > > > + > > > > > > if (!policy->freq_table) > > > > > > - continue; > > > > > > + return -ENXIO; > > > > > > > > > > > > ret = cpufreq_frequency_table_cpuinfo(policy, > > > > > > policy->freq_table); > > > > > > if (ret) { > > > > > > pr_err("%s: Policy frequency update failed\n", > > > > > > __func__); > > > > > > - break; > > > > > > + return ret; > > > > > > } > > > > > > > > > > > > ret = freq_qos_update_request(policy->max_freq_req, policy->max); > > > > > > if (ret < 0) > > > > > > - break; > > > > > > + return ret; > > > > > > } > > > > > > > > > > > > - return ret; > > > > > > + return 0; > > > > > > } > > > > > > > > > > > > int cpufreq_boost_trigger_state(int state) > > > > > > > > > > Acked-by: Viresh Kumar > > > > > > > > Ok. Thanks for the comments. Shall I resend the patch with update Rafael > > > > suggests or you'll merge the Rafael's fix in yourself? > > > > > > I'll apply the fix directly, thanks! > > > > Great. Is it going to be available in the repo: > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/ > > ? > > Yes, it is. Please see the bleeding-edge branch in there, thanks! No credits with at least Reported-by tag? That's sad.( -Sergey