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.
next prev parent reply other threads:[~2013-03-07 11:49 UTC|newest]
Thread overview: 15+ 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 10:52 ` Russell King - ARM Linux
2013-03-05 16:38 ` Viresh Kumar
2013-03-06 17:25 ` Russell King - ARM Linux
2013-03-06 23:09 ` Viresh Kumar
2013-03-07 0:32 ` Viresh Kumar
2013-03-07 0:49 ` Harvey Harrison
2013-03-07 1:46 ` Viresh Kumar
2013-03-07 0:51 ` Russell King - ARM Linux
2013-03-07 2:03 ` Viresh Kumar
2013-03-07 11:49 ` Russell King - ARM Linux [this message]
2013-03-07 17:04 ` Viresh Kumar
2013-03-07 1:46 ` Olof Johansson
2013-03-07 1:50 ` Olof Johansson
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=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).