On Fri, Feb 26, 2016 at 5:31 PM, Li Yang <leoli@xxxxxxxxxxxxx> wrote: > On Fri, Feb 26, 2016 at 5:16 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> On Friday 26 February 2016 17:07:09 Li Yang wrote: >>> >>> I don't have a perfect solution either. But I think this is still >>> better than making cpufreq not usable. The cpufreq driver will print >>> out an error message if thermal is not reachable. Maybe this can >>> relief the confusion a little bit? >> >> With my patch, the configuration will just force the cpufreq >> driver to be a loadable module as well if thermal is a module, >> so the dependency can be resolved by loading the thermal module first. > > It would be perfect if this it true. But I tried with the following > change, it just makes QORIQ_CPUFREQ non-selectable if THERMAL=m. > > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index dcb972a38fbc..ca05037dd565 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -297,6 +297,7 @@ endif > config QORIQ_CPUFREQ > tristate "CPU frequency scaling driver for Freescale QorIQ SoCs" > depends on OF && COMMON_CLK && (PPC_E500MC || ARM) > + depends on !CPU_THERMAL || THERMAL=y > select CLK_QORIQ > help > This adds the CPUFreq driver support for Freescale QorIQ SoCs I find we can achieve your desired result with the following change instead: + depends on (THERMAL=m && m) || THERMAL=y || THERMAL=n Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
