All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active
Date: Mon, 19 Oct 2015 09:44:15 +0100	[thread overview]
Message-ID: <5624AD5F.7020807@arm.com> (raw)
In-Reply-To: <1445243581.2831.9.camel@linaro.org>



On 19/10/15 09:33, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote:
>>

[...]

>>
>> OK, I understand what you mean now. I don't have a strong opinion, but
>> here is the reason why I prefer the approach I said earlier:
>> clk_set_rate doesn't return error if the h/w or f/w return error which
>> is usually the last step. So calling clk_get_rate when clk_set_rate
>> return error quite early makes no sense to me.
>
> It doesn't to me either, but my suggested code doesn't do that, it only
> calls clk_get_rate if the is _no_ error from clk_set_rate, the pseudo
> code again...
>
> ret = clk_set_rate()
> if(!ret)                         /* if no error from clk_set_rate   */
>      if(clk_get_rate()!=correct)  /* but some additional checks fail */
>          ret = -EIO;              /* then indicate an error anyway   */
>
> !ret is ret==0 is 'no error' as the comment says. So the clock framework
> thinks the rate was set OK and we then use clk_get_rate to see if those
> unreported h/w or f/w errors mean that it actually wasn't set OK.
>

Ah sorry, my mistake. May be I got carried away by that extra if(!ret).
I am fine with the patch.

Acked-by: Sudeep Holla <sudeep.holla@arm.com>

-- 
Regards,
Sudeep

      reply	other threads:[~2015-10-19  8:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 17:38 [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active Jon Medhurst (Tixy)
2015-10-07 17:39 ` Viresh Kumar
2015-10-08  9:23   ` Jon Medhurst (Tixy)
2015-10-08 11:24     ` Viresh Kumar
2015-10-08 12:55       ` Jon Medhurst (Tixy)
2015-10-08 13:52         ` Viresh Kumar
2015-10-08 14:18         ` Sudeep Holla
2015-10-12 13:20     ` Sudeep Holla
2015-10-13  7:19       ` Jon Medhurst (Tixy)
2015-10-13 10:36         ` Sudeep Holla
2015-10-14  7:12           ` Jon Medhurst (Tixy)
2015-10-14  8:48             ` Sudeep Holla
2015-10-19  8:33               ` Jon Medhurst (Tixy)
2015-10-19  8:44                 ` Sudeep Holla [this message]

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=5624AD5F.7020807@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=tixy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.