Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
	Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Serge Semin <fancer.lancer@gmail.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Paul Burton <paulburton@kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>, Arnd Bergmann <arnd@arndb.de>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mips@vger.kernel.org, devicetree@vger.kernel.org,
	stable@vger.kernel.org, Frederic Weisbecker <frederic@kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Yue Hu <huyue2@yulong.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 20/20] cpufreq: Return zero on success in boost sw setting
Date: Mon, 18 May 2020 11:53:22 +0200	[thread overview]
Message-ID: <a8dfa493-f858-e35d-7e57-78478be555c4@intel.com> (raw)
In-Reply-To: <20200518074142.c6kbofpdlxro2pjz@vireshk-i7>

On 5/18/2020 9:41 AM, Viresh Kumar wrote:
> On 16-05-20, 15:52, Serge Semin wrote:
>> On Fri, May 15, 2020 at 05:58:47PM +0200, Rafael J. Wysocki wrote:
>>>> @@ -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.
>> Could you elaborate why? Viresh seems to be ok with this solution.
> And it is absolutely fine for Rafael to not agree with it :)
>
>> As I see it the caller doesn't expect the positive value returned by the
>> original freq_qos_update_request(). It just doesn't need to know whether the
>> effective policy has been updated or not, it only needs to make sure the
>> operations has been successful. Moreover the positive value is related only
>> to the !last! active policy, which doesn't give the caller a full picture
>> of the policy change anyway. So taking all of these into account I'd leave the
>> fix as is.
> Rafael: This function is called via a function pointer, which can call
> this or a platform dependent routine (like in acpi-cpufreq.c), and it
> would be reasonable IMO for the return of that callback to only look
> for 0 or negative values, as is generally done in the kernel.

But it only has one caller that can easily check ret < 0 instead of just 
ret, so the extra branch can be saved.

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.

Cheers!



  reply	other threads:[~2020-05-18  9:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200306124807.3596F80307C2@mail.baikalelectronics.ru>
     [not found] ` <20200506174238.15385-1-Sergey.Semin@baikalelectronics.ru>
2020-05-06 17:42   ` [PATCH v2 20/20] cpufreq: Return zero on success in boost sw setting Sergey.Semin
2020-05-15 15:58     ` Rafael J. Wysocki
2020-05-16 12:52       ` Serge Semin
2020-05-18  7:41         ` Viresh Kumar
2020-05-18  9:53           ` Rafael J. Wysocki [this message]
2020-05-18 10:11             ` Viresh Kumar
2020-05-18 10:22               ` Rafael J. Wysocki
2020-05-18 10:24                 ` Viresh Kumar
2020-05-18 10:31                   ` Serge Semin
2020-05-18 10:41                     ` Rafael J. Wysocki
2020-05-18 10:46                       ` Serge Semin
2020-05-18 10:51                         ` Rafael J. Wysocki
2020-05-18 10:56                           ` Serge Semin
2020-05-18 11:05                             ` Rafael J. Wysocki
2020-05-19  1:50                               ` Xiongfeng Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a8dfa493-f858-e35d-7e57-78478be555c4@intel.com \
    --to=rafael.j.wysocki@intel.com \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=frederic@kernel.org \
    --cc=huyue2@yulong.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mka@chromium.org \
    --cc=paulburton@kernel.org \
    --cc=ralf@linux-mips.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=ulf.hansson@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox