Arnd, On Wed, 10 Sep 2014 12:19:41 +0200, Arnd Bergmann wrote: > the driver for every new platform we want to support. It would > be better to find a way that lets you add new platforms using just > new dts files that work with the existing driver. What do you call a "platform" ? A board or a SoC ? The top-level compatible string contain both references to the board and the SoC, and my idea was obviously that the cpufreq driver would match against the SoC compatible string, not the board one. This definitely allows to support additional boards by adding more dts without touching the code. Of course, it however means that when a new SoC shows up, you'll need to adjust the cpufreq driver. But you generally anyway need some kernel changes to support a new SoC: .dtsi changes are rarely sufficient to completely support a new chip. > > In the mean time, would it be possible to realize that the existing > > generic cpufreq driver simply isn't generic enough, and that we should > > accept machine-specific cpufreq drivers for the time being? > > That would work for me, to get things going for 3.18, but it's really > up to the cpufreq maintainers. Your platform_data based patch set > seems like a better solution to me than separate drivers, but I haven't > looked at the details. I personally don't really care: using platform_data, adding a machine-specific driver, having two platform_driver for cpufreq-dt with different names. Viresh ? Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
