On Fri, Feb 26, 2016 at 6:08 PM, Scott Wood <oss@xxxxxxxxxxxx> wrote: > 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. Right. And this is more simpler. 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
