• Rafael J. Wysocki's avatar
    cpufreq: Skip current frequency initialization for ->setpolicy drivers · 2ed99e39
    Rafael J. Wysocki authored
    After commit da60ce9f (cpufreq: call cpufreq_driver->get() after
    calling ->init()) __cpufreq_add_dev() sometimes fails for CPUs handled
    by intel_pstate, because that driver may return 0 from its ->get()
    callback if it has not run long enough to collect enough samples on the
    given CPU.  That didn't happen before commit da60ce9f which added
    policy->cur initialization to __cpufreq_add_dev() to help reduce code
    duplication in other cpufreq drivers.
    
    However, the code added by commit da60ce9f need not be executed
    for cpufreq drivers having the ->setpolicy callback defined, because
    the subsequent invocation of cpufreq_set_policy() will use that
    callback to initialize the policy anyway and it doesn't need
    policy->cur to be initialized upfront.  The analogous code in
    cpufreq_update_policy() is also unnecessary for cpufreq drivers
    having ->setpolicy set and may be skipped for them as well.
    
    Since intel_pstate provides ->setpolicy, skipping the upfront
    policy->cur initialization for cpufreq drivers with that callback
    set will cover intel_pstate and the problem it's been having after
    commit da60ce9f will be addressed.
    
    Fixes: da60ce9f (cpufreq: call cpufreq_driver->get() after calling ->init())
    References: https://bugzilla.kernel.org/show_bug.cgi?id=71931Reported-and-tested-by: default avatarPatrik Lundquist <patrik.lundquist@gmail.com>
    Acked-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
    Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
    Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    2ed99e39
cpufreq.c 60.8 KB