On Fri, 2016-02-26 at 18:04 -0600, Li Yang wrote: > 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 "depends on THERMAL || !THERMAL" should also work. -Scott -- 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
