From: thomas.petazzoni@free-electrons•com (Thomas Petazzoni)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 10/10] cpufreq: mvebu: Use generic platdev driver
Date: Mon, 25 Apr 2016 17:55:03 +0200 [thread overview]
Message-ID: <20160425175503.28ef34d9@free-electrons.com> (raw)
In-Reply-To: <5536968.ADFL5hRmGD@wuerfel>
Hello,
On Mon, 25 Apr 2016 17:46:53 +0200, Arnd Bergmann wrote:
> > What code are you talking about? Initializing the OPPs or adding the
> > cpufreq-dt device? The first one (or whatever is left now in that
> > function) can stay anywhere, even as a cpufreq driver. I was talking
> > about the fact that we don't have a sequence problem to solve here.
>
> My line of thinking was that the armada_xp_pmsu_cpufreq_init()
> function makes sense by itself and feels like it should be
> one file in drivers/cpufreq, including the creation of the device.
>
> Even without the argument of the sequencing, they two parts sort
> of belong together because the cpufreq-dt driver depends on both
> of them being run before it can function. It's also the same amount
> of code, as you are replacing one line in armada_xp_pmsu_cpufreq_init
> with one line in "struct of_device_id machines".
>
> It's not really that important, just a feeling I had that it could
> be done better. Unless the mvebu maintainers feel strongly about
> it, just do as you prefer.
As a mvebu folk, I don't really have a strong opinion on this. We also
have some cpufreq device registration code in
arch/arm/mach-mvebu/kirkwood.c for the older Kirkwood platform, though
this one uses a custom cpufreq driver and not the generic cpufreq-dt
driver.
Ideally, in the grand direction of removing as much things as possible
from mach-<foo> directories, it would be great to move such
initializations somewhere else. But cpufreq is not by far not the only
reason why we still have code in mach-<foo>, at least in the mvebu land.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
prev parent reply other threads:[~2016-04-25 15:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1461228504.git.viresh.kumar@linaro.org>
2016-04-21 8:59 ` [PATCH 08/10] mvebu: Use dev_pm_opp_set_sharing_cpus() to mark OPP tables as shared Viresh Kumar
2016-04-22 22:24 ` Stephen Boyd
2016-04-21 8:59 ` [PATCH 10/10] cpufreq: mvebu: Use generic platdev driver Viresh Kumar
2016-04-22 22:42 ` Arnd Bergmann
2016-04-25 3:00 ` Viresh Kumar
2016-04-25 12:53 ` Arnd Bergmann
2016-04-25 12:56 ` Viresh Kumar
2016-04-25 15:26 ` Arnd Bergmann
2016-04-25 15:29 ` Viresh Kumar
2016-04-25 15:46 ` Arnd Bergmann
2016-04-25 15:55 ` Thomas Petazzoni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160425175503.28ef34d9@free-electrons.com \
--to=thomas.petazzoni@free-electrons$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox