From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Subject: Re: [PATCH v2 4/7] cpufreq: mvebu: Use dev_pm_opp_remove() Date: Tue, 12 Dec 2017 08:28:46 +0100 Message-ID: <20171212082846.4e201953@windsurf.png.is.keysight.com> References: <20171207135616.23670-1-gregory.clement@free-electrons.com> <20171207135616.23670-5-gregory.clement@free-electrons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171207135616.23670-5-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Gregory CLEMENT Cc: "Rafael J. Wysocki" , Viresh Kumar , linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper , Andrew Lunn , Sebastian Hesselbarth , Rob Herring , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Antoine Tenart , =?UTF-8?B?TWlxdcOobA==?= Raynal , Nadav Haklai , Victor Gu , Marcin Wojtas , Wilson Ding , Hua Jing , Neta Zur Hershkovits , Evan Wang , Andre Heider List-Id: linux-pm@vger.kernel.org Hello, On Thu, 7 Dec 2017 14:56:13 +0100, Gregory CLEMENT wrote: > - /* > - * In case of a failure of dev_pm_opp_add(), we don't > - * bother with cleaning up the registered OPP (there's > - * no function to do so), and simply cancel the > - * registration of the cpufreq device. > - */ > ret = dev_pm_opp_add(cpu_dev, clk_get_rate(clk), 0); > if (ret) { > clk_put(clk); > @@ -90,6 +84,11 @@ static int __init armada_xp_pmsu_cpufreq_init(void) > > ret = dev_pm_opp_add(cpu_dev, clk_get_rate(clk) / 2, 0); > if (ret) { > + /* > + * The second opp failed to be added, remove > + * the first one before exiting. > + */ > + dev_pm_opp_remove(cpu_dev, clk_get_rate(clk)); > clk_put(clk); > return ret; > } This still doesn't fix the failure situation. Indeed, you are only removing the OPP at full rate for the current CPU, but you are not removing the OPPs for the N-1 previous CPUs that have been handled in previous iterations of the loop. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html