On Monday, September 12, 2016 12:07:05 PM Viresh Kumar wrote: > If a cpufreq driver is registered very early in the boot stage (e.g. > registered from postcore_initcall()), then cpufreq core may generate > kernel warnings for it. > > In this case, the CPUs are brought online, then the cpufreq driver is > registered, and then the CPU topology devices are registered. However, > by the time cpufreq_add_dev() gets called, the cpu device isn't stored > in the per-cpu variable (cpu_sys_devices,) which is read by > get_cpu_device(). > > So the cpufreq core fails to get device for the CPU, for which > cpufreq_add_dev() was called in the first place and we will hit a > WARN_ON(!cpu_dev). > > Even if we reuse the 'dev' parameter passed to cpufreq_add_dev() to > avoid that warning, there might be other CPUs online that share the > policy with the cpu for which cpufreq_add_dev() is called. Eventually > get_cpu_device() will return NULL for them as well, and we will hit the > same WARN_ON() again. > > In order to fix these issues, change cpufreq core to create links to the > policy for a cpu only when cpufreq_add_dev() is called for that CPU. > > Reuse the 'real_cpus' mask to track that as well. > > Note that cpufreq_remove_dev() already handles removal of the links for > individual CPUs and cpufreq_add_dev() has aligned with that now. > > Reported-by: Russell King <rmk+ker...@arm.linux.org.uk> > Tested-by: Russell King <rmk+ker...@arm.linux.org.uk> > Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
Applied. Thanks, Rafael
