On Wed, Jul 23, 2014 at 01:55:57PM +0530, Viresh Kumar wrote: > On 23 July 2014 12:54, Thierry Reding wrote: > > ARM_TEGRA_CPUFREQ is still optional, so the select only applies when the > > Tegra cpufreq driver is enabled. This is mostly just out of convenience, > > though. The Tegra cpufreq driver uses the generic CPU0 cpufreq driver so > > a select will automatically pull in the necessary dependency. With a > > Not necessarily. cpufreq-cpu0 can have few unmet dependency. And so > there are chances that tegra driver is compiled but cpufreq-cpu0 isn't as > we didn't mention it as a *hard* dependency. > > And so at boot, there wouldn't be any cpufreq support even when tegra's > cpufreq driver is available. > > Though, menuconfig may give some warnings no such situations. > > > "depends on" the Tegra cpufreq driver only becomes available after > > you've selected GENERIC_CPUFREQ_CPU0, which is somewhat unintuitive. > > > > To illustrate with an example: as a user, I want to enable CPU frequency > > scaling on Tegra. So I use menuconfig to navigate to the "CPU Frequency > > scaling" menu (enable it if not available yet) and look for an entry > > that says "Tegra". But I can't find it because it's hidden due to the > > lack of GENERIC_CPUFREQ_CPU0. That the Tegra CPU frequency driver uses a > > generic driver is an implementation detail that users shouldn't have to > > be aware of. > > Don't know, the guy compiling out stuff should be knowledgeable enough to > have a look why tegra cpufreq entry isn't shown in menu. As, probably the > above problem I mentioned looks to be of more significance than this one, > atleast to me :) > > And, another thing to mention is that CONFIG_TEGRA_CPUFREQ is valid > for earlier platforms as well and so a select/depends wouldn't be valid for > earlier platforms. We probably need another Kconfig entry here. Yes, sounds like a new Kconfig entry for this specific driver would be a better approach and should remove all the above concerns. Thierry