Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932384AbcDYMyf (ORCPT ); Mon, 25 Apr 2016 08:54:35 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:52391 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932139AbcDYMye (ORCPT ); Mon, 25 Apr 2016 08:54:34 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Viresh Kumar , nm@ti.com, Andrew Lunn , linaro-kernel@lists.linaro.org, Jason Cooper , linux-pm@vger.kernel.org, sboyd@codeaurora.org, Rafael Wysocki , linux-kernel@vger.kernel.org, Gregory Clement , thomas.petazzoni@free-electrons.com, Sebastian Hesselbarth Subject: Re: [PATCH 10/10] cpufreq: mvebu: Use generic platdev driver Date: Mon, 25 Apr 2016 14:53:49 +0200 Message-ID: <6893237.FoNPbfW3DC@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160425030041.GF22726@vireshk-i7> References: <7576455.rVXD0283Nr@wuerfel> <20160425030041.GF22726@vireshk-i7> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:g9WAotmSKZEbkzCOFMigWXwZW2rn0lean4N7Xu/FIFlyPMsWSrd ga1YFDy+71mVYQBz5D5eECF5aeqfgl2MMBnDJzPyjouUy6pcPTYibtBKo/Oq08ZGy7ZKO01 UMjCCTRR3erSpm69QxytdzmoAvo6n/EARW9RJMOQ8IR7V8ptaGEN6Mc63Zl77lLhiuWatzO CKukkXAPk3VM0weWf7RsQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:6/AVomcLs3M=:vdiY5QCMTjTuimK+kT5cfW R0VZ5PHOmzzxbyPLAs6e3PME7DbuBUJ7PfO48LvVm8vLj/6RpSuXbl4BurOFVxh5elTXZW0tp zGkJhMHvAqVNuMMr0shpSOaVENefO4cuLuMal3Dnb+fDkEkMxoRs8Z7zsHl6YX50DbK8IQWwm R0sQsF784RuD/NsCq1siHb8QMit9i9wuH9ja99Te14qS0rvzemDxxDv5QG0vYckAds5ieu+bP U7/75GDM9JFty2Ic78hewLs6W7sD2EaACHvaM/hDXw8utpWu9CotGgExOEPitIdtoYq8OWI0X F4knaZy3szjIFhogB9XR8MKnjWkR3fOFMu8EThtM5YzWT3MfIu0JV6KMRcTiMRENkcByKExhr HLxPqQ5Anp5ZUJu5tStMfejK20cmmCzOsYLIpqetspsoXxAdUolPmGpaCs6NEHSzuc4Sy8XmZ WGrOSSdTce+OtsqTtbPiaOzN9UC77n3fnOTG00h9G9VPqNL2OflHCwlwyI9qsUBMJmpUMoMwN lEM2JJp2cBScAmY4s175RLwGPWY55rt8F5DaE+c6PN5PwdXo1XcSIGMEmyGZki/6f7uj1LI9S rjnYVU2FnswPmLVEIprK1Pd4izimUt/cQzp/FsrwpRscle0cKqX7YUSoPqHmw3SCkZf6uxORX pWkQHZZW3Pof3ixywbFrCisskiZkxO9Bf5FF6PiALveKEVL1C7U9sM+rAcs1phbR6tkgOPdw0 nYvet3uvonrE+N6U Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2487 Lines: 57 On Monday 25 April 2016 08:30:41 Viresh Kumar wrote: > On 23-04-16, 00:42, Arnd Bergmann wrote: > > On Thursday 21 April 2016 14:29:02 Viresh Kumar wrote: > > > diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c > > > index 79d0a5d9da8e..f24f46776fbb 100644 > > > --- a/arch/arm/mach-mvebu/pmsu.c > > > +++ b/arch/arm/mach-mvebu/pmsu.c > > > @@ -685,8 +685,6 @@ static int __init armada_xp_pmsu_cpufreq_init(void) > > > dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n", > > > __func__, ret); > > > } > > > - > > > - platform_device_register_simple("cpufreq-dt", -1, NULL, 0); > > > return 0; > > > } > > > > > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c > > > index 69b2a222c84e..5704a92c52dc 100644 > > > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > > > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > > > @@ -33,6 +33,8 @@ static const struct of_device_id machines[] = { > > > > > > { .compatible = "marvell,berlin", }, > > > > > > + { .compatible = "marvell,armadaxp", }, > > > + > > > { .compatible = "samsung,exynos3250", }, > > > { .compatible = "samsung,exynos4210", }, > > > { .compatible = "samsung,exynos4212", }, > > > > I think to make it clear that the ordering is significant here, I would leave this > > platform_device_register_simple() in armada_xp_pmsu_cpufreq_init(). > > > > However, it might be helpful to move that function into a new file in > > drivers/cpufreq/ if that works. > > We just can't get wrong with the ordering here, as this is done from > device_initcall() and so that point is out of question. I realize that the ordering is fixed through the way that the kernel is linked, my worry is more about someone changing the code in some way because it's not obvious from reading the code that the dependency exists. If either the armada_xp_pmsu_cpufreq_init() initcall gets changed so it does not always get called, or the cpufreq_dt_platdev_init() initcall gets changed so it comes a little earlier, things will break. > The other thing that can happen is that armada_xp_pmsu_cpufreq_init() > call can fail. In that case, most of the times cpufreq-dt ->init() > will fail as well, so even that is fine for me. > > And, so I think we can keep this patch as is. What are the downsides of moving armada_xp_pmsu_cpufreq_init() into drivers/cpufreq? Arnd