| 2019-03-25 19:55:15 |
dann frazier |
description |
[Impact]
Some HiSilicon SoCs do not implement registers that the cpufreq subsystem uses to calculate current performance. This can result in undefined data being used in internal calculations, and being exposed to userspace via sysfs.
[Test Case]
[Fix]
[Regression Risk]
The fix is a quirk restricted to specific SoCs. It does rely on firmware behaving (overloading the desired_perf register w/ a correct actual perf value), so changes in firmware could lead to regressions. |
[Impact]
Some HiSilicon SoCs do not implement registers that the cpufreq subsystem uses to calculate current performance. This can result in undefined data being used in internal calculations, and being exposed to userspace via sysfs.
[Test Case]
Examine the exposed frequency under idle and load and make sure it looks sane:
sudo cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_cur_freq
Note: On my test system, it happens to look sane w/o this quirk as well. This is because the undefined reads all happen to return 0x1 today, and that puts us into the avoid-divide-by-zero code path that happens to do the same thing as this quirk (report desired perf instead of actual).
[Fix]
6c8d750f9784c cpufreq / cppc: Work around for Hisilicon CPPC cpufreq
1757d05f3112a ACPI / CPPC: Add a helper to get desired performance
[Regression Risk]
The fix is a quirk restricted to specific SoCs. It does rely on firmware behaving (overloading the desired_perf register w/ a correct actual perf value), so changes in firmware could lead to regressions. |
|
