Dear Viresh Kumar, On Wed, 10 Sep 2014 16:08:51 +0530, Viresh Kumar wrote: > Its not that we aren't accepting any drivers at all, but if we can reuse > existing infrastructure then we better use it for long term maintainability. Sure, but when "existing infrastructure" isn't ready to support a particular use case, and there seems to be no solution on which people are agreeing? > But there is another view here which Mike objected to, sometime back. > Its also not a good idea to push everything onto a virtual-cpu-clock > driver.. > > I had something in mind to get that fixed, but this thread hasn't allowed > me to work on that as it should be finished first. > > Probably we can add some callbacks to the cpufreq-cpu0 driver. For > example if somebody wants to do something crazy enough in their > ->target() routine then they can just register their callback and we > will call it instead of cpufreq-dt's target() routine.. > > That way we can still reuse the common part.. I personally don't think it would be a very good idea: in this case, you'd better do a complete cpufreq driver on its own. Doing subsystems in subsystems just for the sake of factorizing 10 lines of initialization seems a bit silly to me. > The platform-data solution is better than any other here :), and that > will get fixed once we get all this including which driver to probe from > DT.. Ok, I'll respin with a different solution than the flags. Thanks, 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
