From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artem Savkov Subject: Re: [PATCH 0/4] CPUFreq Fixes for 3.9 Date: Fri, 8 Feb 2013 10:27:36 +0400 Message-ID: <20130208062736.GA5563@thinkpad.lan> References: <2158181.aoVXdpLJe2@vostro.rjw.lan> <1947746.IyFppZQEx8@vostro.rjw.lan> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=WjJkuJ10ShESGxuFhmdtL2XzgPL72/qEJ1fcgqSToEc=; b=iS6vE7kjQf96rFs41YVZPMYpsYSL3pbiKAkgbaeKxwkVMrA4uEz2/QAEiI10o3kGVl O8gXb9S0H29GR03lhlGR064ig/0Le38sSgKDcPVAInrSUjnjT0Vjd+AtJdu7J/sha5Yk sNjKzrsWgtpPan7oTmLnktLmieruMPzGUxiEBOmLzx6ynTMc0FZmfnklGsV0c2qq4i8A oJ96abIGifJvdNKETP7LF+QjRYpw8XQzbHJEgqetM7ihDnHecG9LQdI0OlurycQ6ueP9 wvM+E6WiCCvOde6QYQGiE9/YrsmSfTZ/ci/lCdvH70ZShf47KEeM20jjv48GGpopQDI+ hDMg== 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: "Rafael J. Wysocki" , valdis.kletnieks@vt.edu, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org, robin.randhawa@arm.com, Steve.Bannister@arm.com, Liviu.Dudau@arm.com, dirk.brandewie@gmail.com On Fri, Feb 08, 2013 at 10:39:13AM +0530, Viresh Kumar wrote: > On 8 February 2013 04:37, Rafael J. Wysocki wrote: > > BTW, there still are locking problems in linux-next. Why do we need > > to take cpufreq_driver_lock() around driver->init() in cpufreq_add_dev(), > > in particular? > I thought a bit more and realized there is no such limitation on > cpufreq_driver->ops about calling routines which can sleep. And thus > we shoudln't > have locks around any of these. I have got a patch for it, that i > would fold-back into > the original patch that introduced locking fixes (attached too for testing): Tested this patch on top of linux-pm.git/bleeding-edge Now everything seems to be alright. > From: Viresh Kumar > Date: Fri, 8 Feb 2013 10:35:31 +0530 > Subject: [PATCH] cpufreq: Remove unnecessary locking > > I have placed some locks intentionally around calls to driver->ops (init/exit), > which look to be wrong as these calls can call routines that potentially sleep. > > Lets remove these locks. > > Signed-off-by: Viresh Kumar > --- > drivers/cpufreq/cpufreq.c | 7 ------- > 1 file changed, 7 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 5d8a422..04aab05 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu, > > if (ret) { > pr_debug("setting policy failed\n"); > - spin_lock_irqsave(&cpufreq_driver_lock, flags); > if (driver->exit) > driver->exit(policy); > - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); > } > return ret; > > @@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev, > struct subsys_interface *sif) > init_completion(&policy->kobj_unregister); > INIT_WORK(&policy->update, handle_update); > > - spin_lock_irqsave(&cpufreq_driver_lock, flags); > /* call driver. From then on the cpufreq must be able > * to accept all calls to ->verify and ->setpolicy for this CPU > */ > ret = driver->init(policy); > if (ret) { > pr_debug("initialization failed\n"); > - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); > goto err_set_policy_cpu; > } > - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); > > /* related cpus should atleast have policy->cpus */ > cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus); > @@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device > *dev, struct subsys_interface *sif > wait_for_completion(cmp); > pr_debug("wait complete\n"); > > - spin_lock_irqsave(&cpufreq_driver_lock, flags); > if (driver->exit) > driver->exit(data); > - spin_unlock_irqrestore(&cpufreq_driver_lock, flags); > > free_cpumask_var(data->related_cpus); > free_cpumask_var(data->cpus); Tested-by: Artem Savkov -- Kind regards, Artem