kernel/git/stable/linux.git/drivers/cpufreq, branch linux-6.0.y

cpufreq: Init completion before kobject_init_and_add()

2023-01-07T10:15:46+00:00

commit 5c51054896bcce1d33d39fead2af73fec24f40b6 upstream. In cpufreq_policy_alloc(), it will call uninitialed completion in cpufreq_sysfs_release() when kobject_init_and_add() fails. And that will cause a crash such as the following page fault in complete: BUG: unable to handle page fault for address: fffffffffffffff8 [..] RIP: 0010:complete+0x98/0x1f0 [..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 4ebe36c94aed ("cpufreq: Fix kobject memleak") Signed-off-by: Yongqiang Liu Acked-by: Viresh Kumar Cc: 5.2+ # 5.2+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: amd_freq_sensitivity: Add missing pci_dev_put()

2022-12-31T12:25:45+00:00

[ Upstream commit 91fda1f88c0968f1491ab150bb01690525af150a ] pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count after using pci_get_device(). Let's add it. Fixes: 59a3b3a8db16 ("cpufreq: AMD: Ignore the check for ProcFeedback in ST/CZ") Signed-off-by: Xiongfeng Wang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: qcom-hw: Fix the frequency returned by cpufreq_driver->get()

2022-12-31T12:25:43+00:00

[ Upstream commit c72cf0cb1d77f6b1b58c334dcc3d09fa13111c4c ] The cpufreq_driver->get() callback is supposed to return the current frequency of the CPU and not the one requested by the CPUFreq core. Fix it by returning the frequency that gets supplied to the CPU after the DCVS operation of EPSS/OSM. Fixes: 2849dd8bc72b ("cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver") Reported-by: Sudeep Holla Signed-off-by: Manivannan Sadhasivam Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: qcom-hw: Fix memory leak in qcom_cpufreq_hw_read_lut()

2022-12-31T12:25:42+00:00

[ Upstream commit 9901c21bcaf2f01fe5078f750d624f4ddfa8f81b ] If "cpu_dev" fails to get opp table in qcom_cpufreq_hw_read_lut(), the program will return, resulting in "table" resource is not released. Fixes: 51c843cf77bb ("cpufreq: qcom: Update the bandwidth levels on frequency change") Signed-off-by: Chen Hui Reviewed-by: Sibi Sankar Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: amd-pstate: cpufreq: amd-pstate: reset MSR_AMD_PERF_CTL register at init

2022-12-02T16:43:11+00:00

commit 919f4557696939625085435ebde09a539de2349c upstream. MSR_AMD_PERF_CTL is guaranteed to be 0 on a cold boot. However, on a kexec boot, for instance, it may have a non-zero value (if the cpu was in a non-P0 Pstate). In such cases, the cores with non-P0 Pstates at boot will never be pushed to P0, let alone boost frequencies. Kexec is a common workflow for reboot on Linux and this creates a regression in performance. Fix it by explicitly setting the MSR_AMD_PERF_CTL to 0 during amd_pstate driver init. Cc: All applicable Acked-by: Huang Rui Reviewed-by: Gautham R. Shenoy Tested-by: Wyes Karny Signed-off-by: Wyes Karny Signed-off-by: Perry Yuan Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: amd-pstate: change amd-pstate driver to be built-in type

2022-12-02T16:43:07+00:00

[ Upstream commit 456ca88d8a5258fc66edc42a10053ac8473de2b1 ] Currently when the amd-pstate and acpi_cpufreq are both built into kernel as module driver, amd-pstate will not be loaded by default in this case. Change amd-pstate driver as built-in type, it will resolve the loading sequence problem to allow user to make amd-pstate driver as the default cpufreq scaling driver. Acked-by: Huang Rui Reviewed-by: Gautham R. Shenoy Tested-by: Wyes Karny Signed-off-by: Perry Yuan Fixes: ec437d71db77 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: intel_pstate: hybrid: Use known scaling factor for P-cores

2022-11-03T15:00:20+00:00

commit f5c8cf2a4992dd929fa0c2f25c09ee69b8dcbce1 upstream. Commit 46573fd6369f ("cpufreq: intel_pstate: hybrid: Rework HWP calibration") attempted to use the information from CPPC (the nominal performance in particular) to obtain the scaling factor allowing the frequency to be computed if the HWP performance level of the given CPU is known or vice versa. However, it turns out that on some platforms this doesn't work, because the CPPC information on them does not align with the contents of the MSR_HWP_CAPABILITIES registers. This basically means that the only way to make intel_pstate work on all of the hybrid platforms to date is to use the observation that on all of them the scaling factor between the HWP performance levels and frequency for P-cores is 78741 (approximately 100000/1.27). For E-cores it is 100000, which is the same as for all of the non-hybrid "core" platforms and does not require any changes. Accordingly, make intel_pstate use 78741 as the scaling factor between HWP performance levels and frequency for P-cores on all hybrid platforms and drop the dependency of the HWP calibration code on CPPC. Fixes: 46573fd6369f ("cpufreq: intel_pstate: hybrid: Rework HWP calibration") Reported-by: Srinivas Pandruvada Acked-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Cc: 5.15+ # 5.15+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: intel_pstate: Read all MSRs on the target CPU

2022-11-03T15:00:20+00:00

commit 8dbab94d45fb1094cefac7956b7fb987a36e2b12 upstream. Some of the MSR accesses in intel_pstate are carried out on the CPU that is running the code, but the values coming from them are used for the performance scaling of the other CPUs. This is problematic, for example, on hybrid platforms where MSR_TURBO_RATIO_LIMIT for P-cores and E-cores is different, so the values read from it on a P-core are generally not applicable to E-cores and the other way around. For this reason, make the driver access all MSRs on the target CPU on platforms using the "core" pstate_funcs callbacks which is the case for all of the hybrid platforms released to date. For this purpose, pass a CPU argument to the ->get_max(), ->get_max_physical(), ->get_min() and ->get_turbo() pstate_funcs callbacks and from there pass it to rdmsrl_on_cpu() or rdmsrl_safe_on_cpu() to access the MSR on the target CPU. Fixes: 46573fd6369f ("cpufreq: intel_pstate: hybrid: Rework HWP calibration") Acked-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Cc: 5.15+ # 5.15+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: qcom: fix memory leak in error path

2022-10-29T08:08:30+00:00

commit 9f42cf54403a42cb092636804d2628d8ecf71e75 upstream. If for some reason the speedbin length is incorrect, then there is a memory leak in the error path because we never free the speedbin buffer. This commit fixes the error path to always free the speedbin buffer. Cc: v5.7+ # v5.7+ Fixes: a8811ec764f9 ("cpufreq: qcom: Add support for krait based socs") Signed-off-by: Fabien Parent Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman

cpufreq: tegra194: Fix module loading

2022-10-29T08:08:30+00:00

commit 1dcaf30725c32b26daa70d22083999972ab99c29 upstream. When the Tegra194 CPUFREQ driver is built as a module it is not automatically loaded as expected on Tegra194 devices. Populate the MODULE_DEVICE_TABLE to fix this. Cc: v5.9+ # v5.9+ Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver") Signed-off-by: Jon Hunter Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman