kernel/linux.git/drivers/cpufreq, branch v4.19.112

cpufreq: brcmstb-avs-cpufreq: Fix types for voltage/frequency

2020-01-27T13:50:53+00:00

[ Upstream commit 4c5681fcc684c762b09435de3e82ffeee7769d21 ] What we read back from the register is going to be capped at 32-bits, and cpufreq_freq_table.frequency is an unsigned int. Avoid any possible value truncation by using the appropriate return value. Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Signed-off-by: Florian Fainelli Acked-by: Markus Mayer Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: brcmstb-avs-cpufreq: Fix initial command check

2020-01-27T13:50:53+00:00

[ Upstream commit 22a26cc6a51ef73dcfeb64c50513903f6b2d53d8 ] There is a logical error in brcm_avs_is_firmware_loaded() whereby if the firmware returns -EINVAL, we will be reporting this as an error. The comment is correct, the code was not. Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Signed-off-by: Florian Fainelli Acked-by: Markus Mayer Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull

2020-01-12T11:17:24+00:00

commit 2733fb0d0699246711cf622e0e2faf02a05b69dc upstream. On i.MX6UL/i.MX6ULL, accessing OCOTP directly is wrong because the ocotp clock needs to be enabled first. Add support for reading OCOTP through the nvmem API, and keep the old method there to support old dtb. Signed-off-by: Anson Huang Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Cc: Sébastien Szymanski Cc: Lucas Stach Signed-off-by: Greg Kroah-Hartman

cpufreq: Register drivers only after CPU devices have been registered

2019-12-31T15:36:01+00:00

[ Upstream commit 46770be0cf94149ca48be87719bda1d951066644 ] The cpufreq core heavily depends on the availability of the struct device for CPUs and if they aren't available at the time cpufreq driver is registered, we will never succeed in making cpufreq work. This happens due to following sequence of events: - cpufreq_register_driver() - subsys_interface_register() - return 0; //successful registration of driver ... at a later point of time - register_cpu(); - device_register(); - bus_probe_device(); - sif->add_dev(); - cpufreq_add_dev(); - get_cpu_device(); //FAILS - per_cpu(cpu_sys_devices, num) = &cpu->dev; //used by get_cpu_device() - return 0; //CPU registered successfully Because the per-cpu variable cpu_sys_devices is set only after the CPU device is regsitered, cpufreq will never be able to get it when cpufreq_add_dev() is called. This patch avoids this failure by making sure device structure of at least CPU0 is available when the cpufreq driver is registered, else return -EPROBE_DEFER. Reported-by: Bjorn Andersson Co-developed-by: Amit Kucheria Signed-off-by: Viresh Kumar Tested-by: Amit Kucheria Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: powernv: fix stack bloat and hard limit on number of CPUs

2019-12-17T19:35:03+00:00

commit db0d32d84031188443e25edbd50a71a6e7ac5d1d upstream. The following build warning occurred on powerpc 64-bit builds: drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is with a cross-compiler based on gcc 8.1.0, which I got from: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ The warning is due to putting 1024 bytes on the stack: unsigned int chip[256]; ...and it's also undesirable to have a hard limit on the number of CPUs here. Fix both problems by dynamically allocating based on num_possible_cpus, as recommended by Michael Ellerman. Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") Signed-off-by: John Hubbard Acked-by: Viresh Kumar Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: Add NULL checks to show() and store() methods of cpufreq

2019-12-01T08:17:39+00:00

commit e6e8df07268c1f75dd9215536e2ce4587b70f977 upstream. Add NULL checks to show() and store() in cpufreq.c to avoid attempts to invoke a NULL callback. Though some interfaces of cpufreq are set as read-only, users can still get write permission using chmod which can lead to a kernel crash, as follows: chmod +w /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq This bug was found in linux 4.19. Signed-off-by: Kai Shen Reported-by: Feilong Lin Reviewed-by: Feilong Lin Acked-by: Viresh Kumar [ rjw: Subject & changelog ] Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown

2019-10-29T08:20:08+00:00

commit 65650b35133ff20f0c9ef0abd5c3c66dbce3ae57 upstream. It is incorrect to set the cpufreq syscore shutdown callback pointer to cpufreq_suspend(), because that function cannot be run in the syscore stage of system shutdown for two reasons: (a) it may attempt to carry out actions depending on devices that have already been shut down at that point and (b) the RCU synchronization carried out by it may not be able to make progress then. The latter issue has been present since commit 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds"), but the former one has been there since commit 90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown") regardless. Fix that by dropping cpufreq_syscore_ops altogether and making device_shutdown() call cpufreq_suspend() directly before shutting down devices, which is along the lines of what system-wide power management does. Fixes: 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds") Fixes: 90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown") Reported-by: Ville Syrjälä Tested-by: Ville Syrjälä Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Cc: 4.0+ # 4.0+ Signed-off-by: Greg Kroah-Hartman

cpufreq/pasemi: fix use-after-free in pas_cpufreq_cpu_init()

2019-08-16T08:12:46+00:00

[ Upstream commit e0a12445d1cb186d875410d093a00d215bec6a89 ] The cpu variable is still being used in the of_get_property() call after the of_node_put() call, which may result in use-after-free. Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak") Signed-off-by: Wen Yang Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: kirkwood: fix possible object reference leak

2019-05-31T13:46:24+00:00

[ Upstream commit 7c468966f05ac9c17bb5948275283d34e6fe0660 ] The call to of_get_child_by_name returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/kirkwood-cpufreq.c:127:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 118, but without a corresponding object release within this function. ./drivers/cpufreq/kirkwood-cpufreq.c:133:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 118, but without a corresponding object release within this function. and also do some cleanup: - of_node_put(np); - np = NULL; ... of_node_put(np); Signed-off-by: Wen Yang Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: pmac32: fix possible object reference leak

2019-05-31T13:46:24+00:00

[ Upstream commit 8d10dc28a9ea6e8c02e825dab28699f3c72b02d9 ] The call to of_find_node_by_name returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/pmac32-cpufreq.c:557:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 552, but without a corresponding object release within this function. ./drivers/cpufreq/pmac32-cpufreq.c:569:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 552, but without a corresponding object release within this function. ./drivers/cpufreq/pmac32-cpufreq.c:598:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 587, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: linux-pm@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin