summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/exynos5440-cpufreq.c
diff options
context:
space:
mode:
authorTao Wang <kevin.wangtao@hisilicon.com>2018-05-26 10:16:48 +0300
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2018-05-30 11:11:34 +0300
commitc7d1f119c48f64bebf0fa1e326af577c6152fe30 (patch)
treeceda0572ac2952d6ee2832034e3724b50a425838 /drivers/cpufreq/exynos5440-cpufreq.c
parentdc628cdf5c2c28bb6e34b207cbe542bc2f4369f8 (diff)
downloadlinux-c7d1f119c48f64bebf0fa1e326af577c6152fe30.tar.xz
cpufreq: Fix new policy initialization during limits updates via sysfs
If the policy limits are updated via cpufreq_update_policy() and subsequently via sysfs, the limits stored in user_policy may be set incorrectly. For example, if both min and max are set via sysfs to the maximum available frequency, user_policy.min and user_policy.max will also be the maximum. If a policy notifier triggered by cpufreq_update_policy() lowers both the min and the max at this point, that change is not reflected by the user_policy limits, so if the max is updated again via sysfs to the same lower value, then user_policy.max will be lower than user_policy.min which shouldn't happen. In particular, if one of the policy CPUs is then taken offline and back online, cpufreq_set_policy() will fail for it due to a failing limits check. To prevent that from happening, initialize the min and max fields of the new_policy object to the ones stored in user_policy that were previously set via sysfs. Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject & changelog ] Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/cpufreq/exynos5440-cpufreq.c')
0 files changed, 0 insertions, 0 deletions