Hi Thierry, > On Mon, Nov 17, 2014 at 12:50:13PM +0100, Lukasz Majewski wrote: > > Hi Thierry, > > > > > On Fri, Nov 14, 2014 at 12:47:33PM +0200, Mikko Perttunen wrote: > > > > Tested-by: Mikko Perttunen <mikko.perttunen@xxxxxxxx> > > > > > > > > One potential issue I can see is that if the cpufreq driver > > > > fails to probe then you'll never get the thermal driver either. > > > > For example, Tegra124 currently has no cpufreq driver, so if > > > > CONFIG_CPU_THERMAL was enabled, then the soctherm driver would > > > > never be able to probe. But I don't really have a solution for > > > > this either. > > > > > > It doesn't seem like there's any code whatsoever to deal with > > > cpufreq within the soctherm driver, so deferring probe based on > > > something we're not using anyway seems rather useless. > > > > So, If I understood you correctly - this patch is not needed in the > > /tegra_soctherm.c:[tegra_defconfig] driver and can be safely > > omitted in v2 of this driver. > > What I'm saying is that I don't think doing this mass conversion > wholesale is useful since none of the drivers register a cooling > device based on cpufreq. In other words: if you're not going to use a > feature there's no use testing for it. > It seems, like one option here would be to add deferred proble to cpufreq_cooling_register() or check which driver in its thermal probe is calling cpufreq_cooling_register() function. The latter option explains why in the imx_thermal.c file we check for deferred probe without #ifdefs for CONFIG_CPU_THERMAL. If no objections, I would like to stick to the code already available in imx_thermal.c. > Thierry -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
