lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 7 Mar 2013 11:49:50 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	rjw@...k.pl, Steve.Bannister@....com, linux-pm@...r.kernel.org,
	Sudeep KarkadaNagesha <sudeep.karkadanagesha@....com>,
	Liviu.Dudau@....com, linux-kernel@...r.kernel.org,
	cpufreq@...r.kernel.org, robin.randhawa@....com,
	linux-arm-kernel@...ts.infradead.org, mark.hambleton@...adcom.com,
	linaro-kernel@...ts.linaro.org, charles.garcia-tobin@....com
Subject: Re: [PATCH] cpufreq: ARM big LITTLE: Add generic cpufreq driver
	and its DT glue

On Thu, Mar 07, 2013 at 10:03:28AM +0800, Viresh Kumar wrote:
> On 7 March 2013 08:51, Russell King - ARM Linux <linux@....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@....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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ