linux-stable.git/drivers/cpufreq, branch v5.4.78

acpi-cpufreq: Honor _PSD table setting on new AMD CPUs

2020-11-05T10:43:25+00:00

commit 5368512abe08a28525d9b24abbfc2a72493e8dba upstream.

acpi-cpufreq has a old quirk that overrides the _PSD table supplied by
BIOS on AMD CPUs. However the _PSD table of new AMD CPUs (Family 19h+)
now accurately reports the P-state dependency of CPU cores. Hence this
quirk needs to be fixed in order to support new CPUs' frequency control.

Fixes: acd316248205 ("acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs")
Signed-off-by: Wei Huang 
[ rjw: Subject edit ]
Cc: 3.10+  # 3.10+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: sti-cpufreq: add stih418 support

2020-11-05T10:43:17+00:00

[ Upstream commit 01a163c52039e9426c7d3d3ab16ca261ad622597 ]

The STiH418 can be controlled the same way as STiH407 &
STiH410 regarding cpufreq.

Signed-off-by: Alain Volmat 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_reboot_notifier

2020-10-29T08:57:51+00:00

[ Upstream commit a2d0230b91f7e23ceb5d8fb6a9799f30517ec33a ]

The patch avoids allocating cpufreq_policy on stack hence fixing frame
size overflow in 'powernv_cpufreq_reboot_notifier':

  drivers/cpufreq/powernv-cpufreq.c: In function powernv_cpufreq_reboot_notifier:
  drivers/cpufreq/powernv-cpufreq.c:906:1: error: the frame size of 2064 bytes is larger than 2048 bytes

Fixes: cf30af76 ("cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec")
Signed-off-by: Srikar Dronamraju 
Reviewed-by: Daniel Axtens 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20200922080254.41497-1-srikar@linux.vnet.ibm.com
Signed-off-by: Sasha Levin

cpufreq: armada-37xx: Add missing MODULE_DEVICE_TABLE

2020-10-29T08:57:40+00:00

[ Upstream commit c942d1542f1bc5001216fabce9cb8ffbe515777e ]

CONFIG_ARM_ARMADA_37XX_CPUFREQ is tristate option and therefore this
cpufreq driver can be compiled as a module. This patch adds missing
MODULE_DEVICE_TABLE which generates correct modalias for automatic
loading of this cpufreq driver when is compiled as an external module.

Reviewed-by: Andrew Lunn 
Signed-off-by: Pali Rohár 
Fixes: 92ce45fb875d7 ("cpufreq: Add DVFS support for Armada 37xx")
[ Viresh: Added __maybe_unused ]
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_work_fn

2020-10-01T11:17:47+00:00

[ Upstream commit d95fe371ecd28901f11256c610b988ed44e36ee2 ]

The patch avoids allocating cpufreq_policy on stack hence fixing frame
size overflow in 'powernv_cpufreq_work_fn'

Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling")
Signed-off-by: Pratik Rajesh Sampat 
Reviewed-by: Daniel Axtens 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20200316135743.57735-1-psampat@linux.ibm.com
Signed-off-by: Sasha Levin

cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled

2020-09-17T11:47:49+00:00

[ Upstream commit eacc9c5a927e474c173a5d53dd7fb8e306511768 ]

This fixes the behavior of the scaling_max_freq and scaling_min_freq
sysfs files in systems which had turbo disabled by the BIOS.

Caleb noticed that the HWP is programmed to operate in the wrong
P-state range on his system when the CPUFREQ policy min/max frequency
is set via sysfs.  This seems to be because in his system
intel_pstate_get_hwp_max() is returning the maximum turbo P-state even
though turbo was disabled by the BIOS, which causes intel_pstate to
scale kHz frequencies incorrectly e.g. setting the maximum turbo
frequency whenever the maximum guaranteed frequency is requested via
sysfs.

Tested-by: Caleb Callaway 
Signed-off-by: Francisco Jerez 
Acked-by: Srinivas Pandruvada 
[ rjw: Minor subject edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

cpufreq: intel_pstate: Refuse to turn off with HWP enabled

2020-09-17T11:47:49+00:00

[ Upstream commit 43298db3009f06fe5c69e1ca8b6cfc2565772fa1 ]

After commit f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive
mode with HWP enabled") it is possible to change the driver status
to "off" via sysfs with HWP enabled, which effectively causes the
driver to unregister itself, but HWP remains active and it forces the
minimum performance, so even if another cpufreq driver is loaded,
it will not be able to control the CPU frequency.

For this reason, make the driver refuse to change the status to
"off" with HWP enabled.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Srinivas Pandruvada 
Signed-off-by: Sasha Levin

cpufreq: intel_pstate: Fix EPP setting via sysfs in active mode

2020-09-03T09:26:53+00:00

[ Upstream commit de002c55cadfc2f6cdf0ed427526f6085d240238 ]

Because intel_pstate_set_energy_pref_index() reads and writes the
MSR_HWP_REQUEST register without using the cached value of it used by
intel_pstate_hwp_boost_up() and intel_pstate_hwp_boost_down(), those
functions may overwrite the value written by it and so the EPP value
set via sysfs may be lost.

To avoid that, make intel_pstate_set_energy_pref_index() take the
cached value of MSR_HWP_REQUEST just like the other two routines
mentioned above and update it with the new EPP value coming from
user space in addition to updating the MSR.

Note that the MSR itself still needs to be updated too in case
hwp_boost is unset or the boosting mechanism is not active at the
EPP change time.

Fixes: e0efd5be63e8 ("cpufreq: intel_pstate: Add HWP boost utility and sched util hooks")
Reported-by: Francisco Jerez 
Cc: 4.18+  # 4.18+: 3da97d4db8ee cpufreq: intel_pstate: Rearrange ...
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Francisco Jerez 
Signed-off-by: Sasha Levin

cpufreq: intel_pstate: Fix cpuinfo_max_freq when MSR_TURBO_RATIO_LIMIT is 0

2020-08-26T08:40:56+00:00

[ Upstream commit 4daca379c703ff55edc065e8e5173dcfeecf0148 ]

The MSR_TURBO_RATIO_LIMIT can be 0. This is not an error. User can update
this MSR via BIOS settings on some systems or can use msr tools to update.
Also some systems boot with value = 0.

This results in display of cpufreq/cpuinfo_max_freq wrong. This value
will be equal to cpufreq/base_frequency, even though turbo is enabled.

But platform will still function normally in HWP mode as we get max
1-core frequency from the MSR_HWP_CAPABILITIES. This MSR is already used
to calculate cpu->pstate.turbo_freq, which is used for to set
policy->cpuinfo.max_freq. But some other places cpu->pstate.turbo_pstate
is used. For example to set policy->max.

To fix this, also update cpu->pstate.turbo_pstate when updating
cpu->pstate.turbo_freq.

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

cpufreq: dt: fix oops on armada37xx

2020-08-19T06:16:25+00:00

commit 10470dec3decaf5ed3c596f85debd7c42777ae12 upstream.

Commit 0c868627e617e43a295d8 (cpufreq: dt: Allow platform specific
intermediate callbacks) added two function pointers to the
struct cpufreq_dt_platform_data. However, armada37xx_cpufreq_driver_init()
has this struct (pdata) located on the stack and uses only "suspend"
and "resume" fields. So these newly added "get_intermediate" and
"target_intermediate" pointers are uninitialized and contain arbitrary
non-null values, causing all kinds of trouble.

For instance, here is an oops on espressobin after an attempt to change
the cpefreq governor:

[   29.174554] Unable to handle kernel execute from non-executable memory at virtual address ffff00003f87bdc0
...
[   29.269373] pc : 0xffff00003f87bdc0
[   29.272957] lr : __cpufreq_driver_target+0x138/0x580
...

Fixed by zeroing out pdata before use.

Cc:  # v5.7+
Signed-off-by: Ivan Kokshaysky 
Reviewed-by: Andrew Lunn 
Signed-off-by: Viresh Kumar 
Signed-off-by: Greg Kroah-Hartman