On Thursday 24 March 2016 19:36:00 Viresh Kumar wrote:
On 24-03-16, 14:36, Arnd Bergmann wrote:
I've tried implementing something similar when we last discussed it, but didn't get far enough to test it our properly, and I had trouble integrating some of the more complex platforms (omap, imx, sunxi) that have lots of root compatible strings to fit in nicely.
I think having a lookup table as in your patch 2 makes sense here, but I still would prefer not having a device at all. See the patch
We don't have any other option really. The platform-device logic was added to make -EPROBE-DEFER work :)
Hmm, can you give an example where this is needed? I assume you are thinking of some clock controller or regulator that gets initialized after the cpufreq driver, right?
Are there any that are in loadable modules, rather than just later in the init sequence for built-in drivers?
Another idea I had was to make dt_cpufreq_init() a global function that can simply be called by platforms that pass non-NULL platform data today, avoiding the need for the pdata in a global location.
I think its high time that we kill platform data if we don't care about old DT compatibility with new kernel for mvebu platform, if it hasn't gone into product already. We can do everything with opp-v2 now, and pdata doesn't do anything special.
I think we do care about compatibility there, but there are clearly other ways to handle the special case for opp-v1 if we want to.
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index f951f911786e..b3817cc86597 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -356,7 +356,7 @@ static struct cpufreq_driver dt_cpufreq_driver = { .suspend = cpufreq_generic_suspend, }; -static int dt_cpufreq_probe(struct platform_device *pdev) +static int (void *data)
dt_cpufreq_init ? :)
Yes, I must have removed the string from my email when copying the text above.
Arnd