From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [PATCH] cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue Date: Thu, 7 Mar 2013 11:49:50 +0000 Message-ID: <20130307114950.GF17833@n2100.arm.linux.org.uk> References: <20130305105251.GL17833@n2100.arm.linux.org.uk> <20130307005119.GY17833@n2100.arm.linux.org.uk> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=caramon; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=INq5B2quQ3UqOOIFIcul5Fsf9Mv4zU5s+LzPEkHFeKA=; b=gD5cSRTlv1PdYYXW9UtgRg4W8MYVhat0BUcNCNo92R6oB5JW6C9pAf8nSCHgRS58dBP1ni5KT4wFvoLww6J8ApdWiiCiu8SIfhbBNxwcpu6DSRK4JjHCYy+A9DPt8USzuw+oTGy/Zr1Jeb1jQttY60/PBEKzCW9eIDgltlxv8BA=; Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Viresh Kumar Cc: rjw@sisk.pl, Steve.Bannister@arm.com, linux-pm@vger.kernel.org, Sudeep KarkadaNagesha , 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 On Thu, Mar 07, 2013 at 10:03:28AM +0800, Viresh Kumar wrote: > On 7 March 2013 08:51, Russell King - ARM Linux wrote: > > On Thu, Mar 07, 2013 at 08:32:37AM +0800, Viresh Kumar wrote: > >> On 5 March 2013 18:52, Russell King - ARM Linux 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Thu, 7 Mar 2013 11:49:50 +0000 Subject: [PATCH] cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue In-Reply-To: References: <20130305105251.GL17833@n2100.arm.linux.org.uk> <20130307005119.GY17833@n2100.arm.linux.org.uk> Message-ID: <20130307114950.GF17833@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Mar 07, 2013 at 10:03:28AM +0800, Viresh Kumar wrote: > On 7 March 2013 08:51, Russell King - ARM Linux wrote: > > On Thu, Mar 07, 2013 at 08:32:37AM +0800, Viresh Kumar wrote: > >> On 5 March 2013 18:52, Russell King - ARM Linux 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.