Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp609847ybk; Fri, 15 May 2020 09:01:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwf4tcpVPyVGtKB4eO4OjduYxUGXlpwNoZsiiuyten3ST1fTK7wrHuCZu5TrIXhokiyZf+ X-Received: by 2002:a17:906:34c4:: with SMTP id h4mr3553555ejb.167.1589558463504; Fri, 15 May 2020 09:01:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589558463; cv=none; d=google.com; s=arc-20160816; b=j47iCKaYsagzr8cAkFngy1O0v6wLYdkPb36uByRK+SLAvEuB9I29ahXLdDzPpuUbRT WHuTVRj6u+75W9hmYHZvhPC00+oC1GaNTemsXJm07YUZ85UDEWnoh66isdKXVBWBjzMy zsUsITBG9k82r4dxmuzsFB36uNo3BpODB2JV4XEAjEx8b2FBbvathv6t2Fdnst/oUWcm QeEhv9zdS9MFj094U3LwiDy3Ei9YNY0Qp6FV/Ei6PhtppWkSeTsov1vk13INLvGx8bLS 20fRmjwD3eEnHegf/Vpmvjzq+p/bIPNyOgLkHK25GnufuXCUFjyrEcIzgM3DeqCQ8jxG YrVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject:ironport-sdr :ironport-sdr; bh=emlNnAt9X52T537gcc2gg97rki+pCRTKkiNuUilM9Zw=; b=Yq+ub7koFfaaTgMbTg3GCWFOWWArMESqv0B6kUlnd7E8Lf5vmhkg+u8NMTf8adJWaP BlAT+1l/lkHXExTZzQU9JSFnKJkqm6uxmPamb5NVoNJA/X7i/VlniAY+84XJwx5/xpWy GQEPHeNj0Ngj5ItNFW9ISB7vHysMnri4H1lO7dMZHUNiyPA37As6NCgvkcQAy4DObgbu GGME1KrAnhKHuXEznRLKHmLC4emU24AaFQy+eINy+mzQUBfpfe5/xJtY++XtbUKLAQG4 dmShN4Eo7Icg0QeFz0l8cfIUYQ92YVJxJ+29KyMR6XG5UujIgGjYGVfPyP+lncsN/eb2 olow== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j5si1607070ejj.183.2020.05.15.09.00.24; Fri, 15 May 2020 09:01:03 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726720AbgEOP6y (ORCPT + 99 others); Fri, 15 May 2020 11:58:54 -0400 Received: from mga11.intel.com ([192.55.52.93]:23856 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726407AbgEOP6x (ORCPT ); Fri, 15 May 2020 11:58:53 -0400 IronPort-SDR: 2mHQnDI+cDVuxPl4+6x4XzYcU9BCzxzHCrj7+4wEp8s+/sre3qQeA2EMi46obvskbTsdfHECEA YPKufeby6AzA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 May 2020 08:58:53 -0700 IronPort-SDR: HirYw8rAPztdjIA+/NI+F9pTHI7jr2RVdgGVqpP6A1KNTRdCnoAGKJuyB90njmSwKQdRaaUe4r 3Fk2+H3/lEUQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,395,1583222400"; d="scan'208";a="263229930" Received: from rjwysock-mobl1.ger.corp.intel.com (HELO [10.249.131.101]) ([10.249.131.101]) by orsmga003.jf.intel.com with ESMTP; 15 May 2020 08:58:48 -0700 Subject: Re: [PATCH v2 20/20] cpufreq: Return zero on success in boost sw setting To: Sergey.Semin@baikalelectronics.ru, Thomas Bogendoerfer , "Rafael J. Wysocki" , Viresh Kumar , Ulf Hansson , Matthias Kaehlcke Cc: Serge Semin , Alexey Malahov , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , linux-mips@vger.kernel.org, devicetree@vger.kernel.org, stable@vger.kernel.org, Frederic Weisbecker , Ingo Molnar , Yue Hu , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200306124807.3596F80307C2@mail.baikalelectronics.ru> <20200506174238.15385-1-Sergey.Semin@baikalelectronics.ru> <20200506174238.15385-21-Sergey.Semin@baikalelectronics.ru> From: "Rafael J. Wysocki" Organization: Intel Technology Poland Sp. z o. o., KRS 101882, ul. Slowackiego 173, 80-298 Gdansk Message-ID: Date: Fri, 15 May 2020 17:58:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200506174238.15385-21-Sergey.Semin@baikalelectronics.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/6/2020 7:42 PM, Sergey.Semin@baikalelectronics.ru wrote: > From: Serge Semin > > Recent commit e61a41256edf ("cpufreq: dev_pm_qos_update_request() can > return 1 on success") fixed a problem when active policies traverse > was falsely stopped due to invalidly treating the non-zero return value > from freq_qos_update_request() method as an error. Yes, that function > can return positive values if the requested update actually took place. > The current problem is that the returned value is then passed to the > return cell of the cpufreq_boost_set_sw() (set_boost callback) method. > This value is then also analyzed for being non-zero, which is also > treated as having an error. As a result during the boost activation > we'll get an error returned while having the QOS frequency update > successfully performed. Fix this by returning a negative value from the > cpufreq_boost_set_sw() if actual error was encountered and zero > otherwise treating any positive values as the successful operations > completion. > > Fixes: 18c49926c4bf ("cpufreq: Add QoS requests for userspace constraints") > Signed-off-by: Serge Semin > Acked-by: Viresh Kumar > Cc: Alexey Malahov > Cc: Thomas Bogendoerfer > Cc: Paul Burton > Cc: Ralf Baechle > Cc: Arnd Bergmann > Cc: Rob Herring > Cc: linux-mips@vger.kernel.org > Cc: devicetree@vger.kernel.org > Cc: stable@vger.kernel.org > --- > drivers/cpufreq/cpufreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 045f9fe157ce..5870cdca88cf 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -2554,7 +2554,7 @@ static int cpufreq_boost_set_sw(int state) > break; > } > > - return ret; > + return ret < 0 ? ret : 0; > } > > int cpufreq_boost_trigger_state(int state) IMO it is better to update the caller of this function to handle the positive value possibly returned by it correctly. Thanks!