All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: rjw@sisk.pl, Steve.Bannister@arm.com, linux-pm@vger.kernel.org,
	Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>,
	Liviu.Dudau@arm.com, linux-kernel@vger.kernel.org,
	cpufreq@vger.kernel.org, robin.randhawa@arm.com,
	linux-arm-kernel@lists.infradead.org,
	mark.hambleton@broadcom.com, linaro-kernel@lists.linaro.org,
	charles.garcia-tobin@arm.com
Subject: Re: [PATCH] cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue
Date: Thu, 7 Mar 2013 11:49:50 +0000	[thread overview]
Message-ID: <20130307114950.GF17833@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAKohpok7aD-J-undUisxaOotbXWimPo46jqOH4ok04kg_hMWHA@mail.gmail.com>

On Thu, Mar 07, 2013 at 10:03:28AM +0800, Viresh Kumar wrote:
> On 7 March 2013 08:51, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Thu, Mar 07, 2013 at 08:32:37AM +0800, Viresh Kumar wrote:
> >> On 5 March 2013 18:52, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Mar 05, 2013 at 12:52:41PM +0800, Viresh Kumar wrote:
> >> >> +     clk[cluster] = clk_get(NULL, name);
> >> >> +     if (!IS_ERR_OR_NULL(clk[cluster])) {
> >> >
> >> > NAK.  Two reasons.
> >> >
> >> > 1. IS_ERR_OR_NULL.  You know about this, it's been on the list several
> >> >    times.
> >>
> >> Hey, i had a second thought about this one and i have some other opinion
> >> here. This is a cpufreq driver and we need clock support for sure here, we
> >> can't work without it. And so here is the latest fixup:
> >
> > NAK.  You just don't understand.
> 
> Poor me!!
> 
> I still remember the huge discussions we had during "clk: Add non
> CONFIG_HAVE_CLK routines" patchset.
> 
> For others: https://lkml.org/lkml/2012/4/24/389
> 
> Back to the discussion, I understand that clk_get() just returns a cookie and
> NULL is not an error and so it shouldn't be treated specially. And that's what
> we do with most of our drivers as all other clk routines (clk_get[set]_rate())
> have safe guards against the NULL clk, and they wouldn't complain.
> 
> The special case we have in a cpufreq driver is, we can't work with
> zero returned
> from clk_get_rate()... That will make cpufreq driver work badly.

So how is this different from any other clock which may also return zero
from its clk_get_rate() ?

If that's the condition you want to check for, call clk_get_rate() after
a successful clk_get*() and check for the condition.  Don't go treating
the cookie somehow specially.  You're *assuming* a behaviour that is
inappropriate for the side of the interface you're working with.

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue
Date: Thu, 7 Mar 2013 11:49:50 +0000	[thread overview]
Message-ID: <20130307114950.GF17833@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAKohpok7aD-J-undUisxaOotbXWimPo46jqOH4ok04kg_hMWHA@mail.gmail.com>

On Thu, Mar 07, 2013 at 10:03:28AM +0800, Viresh Kumar wrote:
> On 7 March 2013 08:51, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Thu, Mar 07, 2013 at 08:32:37AM +0800, Viresh Kumar wrote:
> >> On 5 March 2013 18:52, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Mar 05, 2013 at 12:52:41PM +0800, Viresh Kumar wrote:
> >> >> +     clk[cluster] = clk_get(NULL, name);
> >> >> +     if (!IS_ERR_OR_NULL(clk[cluster])) {
> >> >
> >> > NAK.  Two reasons.
> >> >
> >> > 1. IS_ERR_OR_NULL.  You know about this, it's been on the list several
> >> >    times.
> >>
> >> Hey, i had a second thought about this one and i have some other opinion
> >> here. This is a cpufreq driver and we need clock support for sure here, we
> >> can't work without it. And so here is the latest fixup:
> >
> > NAK.  You just don't understand.
> 
> Poor me!!
> 
> I still remember the huge discussions we had during "clk: Add non
> CONFIG_HAVE_CLK routines" patchset.
> 
> For others: https://lkml.org/lkml/2012/4/24/389
> 
> Back to the discussion, I understand that clk_get() just returns a cookie and
> NULL is not an error and so it shouldn't be treated specially. And that's what
> we do with most of our drivers as all other clk routines (clk_get[set]_rate())
> have safe guards against the NULL clk, and they wouldn't complain.
> 
> The special case we have in a cpufreq driver is, we can't work with
> zero returned
> from clk_get_rate()... That will make cpufreq driver work badly.

So how is this different from any other clock which may also return zero
from its clk_get_rate() ?

If that's the condition you want to check for, call clk_get_rate() after
a successful clk_get*() and check for the condition.  Don't go treating
the cookie somehow specially.  You're *assuming* a behaviour that is
inappropriate for the side of the interface you're working with.

  reply	other threads:[~2013-03-07 11:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05  4:52 [PATCH] cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue Viresh Kumar
2013-03-05  4:52 ` Viresh Kumar
2013-03-05 10:52 ` Russell King - ARM Linux
2013-03-05 10:52   ` Russell King - ARM Linux
2013-03-05 16:38   ` Viresh Kumar
2013-03-05 16:38     ` Viresh Kumar
2013-03-06 17:25     ` Russell King - ARM Linux
2013-03-06 17:25       ` Russell King - ARM Linux
2013-03-06 23:09       ` Viresh Kumar
2013-03-06 23:09         ` Viresh Kumar
2013-03-07  0:32   ` Viresh Kumar
2013-03-07  0:32     ` Viresh Kumar
2013-03-07  0:49     ` Harvey Harrison
2013-03-07  0:49       ` Harvey Harrison
2013-03-07  1:46       ` Viresh Kumar
2013-03-07  1:46         ` Viresh Kumar
2013-03-07  0:51     ` Russell King - ARM Linux
2013-03-07  0:51       ` Russell King - ARM Linux
2013-03-07  2:03       ` Viresh Kumar
2013-03-07  2:03         ` Viresh Kumar
2013-03-07 11:49         ` Russell King - ARM Linux [this message]
2013-03-07 11:49           ` Russell King - ARM Linux
2013-03-07 17:04           ` Viresh Kumar
2013-03-07 17:04             ` Viresh Kumar
2013-03-07  1:46 ` Olof Johansson
2013-03-07  1:46   ` Olof Johansson
2013-03-07  1:50   ` Olof Johansson
2013-03-07  1:50     ` Olof Johansson
2013-03-07  2:29     ` Viresh Kumar
2013-03-07  2:29       ` Viresh Kumar

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=20130307114950.GF17833@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=Liviu.Dudau@arm.com \
    --cc=Steve.Bannister@arm.com \
    --cc=charles.garcia-tobin@arm.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.hambleton@broadcom.com \
    --cc=rjw@sisk.pl \
    --cc=robin.randhawa@arm.com \
    --cc=sudeep.karkadanagesha@arm.com \
    --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.