kernel.git/drivers/cpufreq/cpufreq.c, branch linux-6.16.y

cpufreq: Initialize cpufreq-based invariance before subsys

2025-10-02T11:48:27Z

[ Upstream commit 8ffe28b4e8d8b18cb2f2933410322c24f039d5d6 ] commit 2a6c72738706 ("cpufreq: Initialize cpufreq-based frequency-invariance later") postponed the frequency invariance initialization to avoid disabling it in the error case. This isn't locking safe, instead move the initialization up before the subsys interface is registered (which will rebuild the sched_domains) and add the corresponding disable on the error path. Observed lockdep without this patch: [ 0.989686] ====================================================== [ 0.989688] WARNING: possible circular locking dependency detected [ 0.989690] 6.17.0-rc4-cix-build+ #31 Tainted: G S [ 0.989691] ------------------------------------------------------ [ 0.989692] swapper/0/1 is trying to acquire lock: [ 0.989693] ffff800082ada7f8 (sched_energy_mutex){+.+.}-{4:4}, at: rebuild_sched_domains_energy+0x30/0x58 [ 0.989705] but task is already holding lock: [ 0.989706] ffff000088c89bc8 (&policy->rwsem){+.+.}-{4:4}, at: cpufreq_online+0x7f8/0xbe0 [ 0.989713] which lock already depends on the new lock. Fixes: 2a6c72738706 ("cpufreq: Initialize cpufreq-based frequency-invariance later") Signed-off-by: Christian Loehle Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: Exit governor when failed to start old governor

2025-08-20T16:40:58Z

[ Upstream commit 0ae204405095abfbc2d694ee0fbb49bcbbe55c57 ] Detect the result of starting old governor in cpufreq_set_policy(). If it fails, exit the governor and clear policy->governor. Signed-off-by: Lifeng Zheng Link: https://patch.msgid.link/20250709104145.2348017-5-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: Init policy->rwsem before it may be possibly used

2025-08-15T14:38:34Z

[ Upstream commit d1378d1d7edb3a4c4935a44fe834ae135be03564 ] In cpufreq_policy_put_kobj(), policy->rwsem is used. But in cpufreq_policy_alloc(), if freq_qos_add_notifier() returns an error, error path via err_kobj_remove or err_min_qos_notifier will be reached and cpufreq_policy_put_kobj() will be called before policy->rwsem is initialized. Thus, the calling of init_rwsem() should be moved to where before these two error paths can be reached. Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework") Signed-off-by: Lifeng Zheng Link: https://patch.msgid.link/20250709104145.2348017-3-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: Initialize cpufreq-based frequency-invariance later

2025-08-15T14:38:33Z

[ Upstream commit 2a6c727387062a2ea79eb6cf5004820cb1b0afe2 ] The cpufreq-based invariance is enabled in cpufreq_register_driver(), but never disabled after registration fails. Move the invariance initialization to where all other initializations have been successfully done to solve this problem. Fixes: 874f63531064 ("cpufreq: report whether cpufreq supports Frequency Invariance (FI)") Signed-off-by: Lifeng Zheng Link: https://patch.msgid.link/20250709104145.2348017-2-zhenglifeng1@huawei.com [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: Update sscanf() to kstrtouint()

2025-05-21T20:27:36Z

In store_scaling_setspeed(), sscanf is still used to read to sysfs. Newer kstrtox provide more features including overflow protection, better errorhandling and allows for other systems of numeration. It is therefore better to update sscanf() to kstrtouint(). Signed-off-by: Bowen Yu Acked-by: Viresh Kumar Link: https://patch.msgid.link/20250519070938.931396-1-yubowen8@huawei.com Signed-off-by: Rafael J. Wysocki

cpufreq: Replace magic number

2025-05-21T20:19:10Z

Setting the length of str_governor with a magic number could cause overflow when max length increases, it is better to use the defined macro in this case. Signed-off-by: Bowen Yu Acked-by: Viresh Kumar Link: https://patch.msgid.link/20250519070908.930879-1-yubowen8@huawei.com Signed-off-by: Rafael J. Wysocki

cpufreq: drop redundant cpus_read_lock() from store_local_boost()

2025-05-14T12:41:15Z

Lockdep reports a possible circular locking dependency [1] when cpu_hotplug_lock is acquired inside store_local_boost(), after policy->rwsem has already been taken by store(). However, the boost update is strictly per-policy and does not access shared state or iterate over all policies. Since policy->rwsem is already held, this is enough to serialize against concurrent topology changes for the current policy. Remove the cpus_read_lock() to resolve the lockdep warning and avoid unnecessary locking. [1] ====================================================== WARNING: possible circular locking dependency detected 6.15.0-rc6-debug-gb01fc4eca73c #1 Not tainted ------------------------------------------------------ power-profiles-/588 is trying to acquire lock: ffffffffb3a7d910 (cpu_hotplug_lock){++++}-{0:0}, at: store_local_boost+0x56/0xd0 but task is already holding lock: ffff8b6e5a12c380 (&policy->rwsem){++++}-{4:4}, at: store+0x37/0x90 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&policy->rwsem){++++}-{4:4}: down_write+0x29/0xb0 cpufreq_online+0x7e8/0xa40 cpufreq_add_dev+0x82/0xa0 subsys_interface_register+0x148/0x160 cpufreq_register_driver+0x15d/0x260 amd_pstate_register_driver+0x36/0x90 amd_pstate_init+0x1e7/0x270 do_one_initcall+0x68/0x2b0 kernel_init_freeable+0x231/0x270 kernel_init+0x15/0x130 ret_from_fork+0x2c/0x50 ret_from_fork_asm+0x11/0x20 -> #1 (subsys mutex#3){+.+.}-{4:4}: __mutex_lock+0xc2/0x930 subsys_interface_register+0x7f/0x160 cpufreq_register_driver+0x15d/0x260 amd_pstate_register_driver+0x36/0x90 amd_pstate_init+0x1e7/0x270 do_one_initcall+0x68/0x2b0 kernel_init_freeable+0x231/0x270 kernel_init+0x15/0x130 ret_from_fork+0x2c/0x50 ret_from_fork_asm+0x11/0x20 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x10ed/0x1850 lock_acquire.part.0+0x69/0x1b0 cpus_read_lock+0x2a/0xc0 store_local_boost+0x56/0xd0 store+0x50/0x90 kernfs_fop_write_iter+0x132/0x200 vfs_write+0x2b3/0x590 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x56/0x5e Signed-off-by: Seyediman Seyedarab Link: https://patch.msgid.link/20250513015726.1497-1-ImanDevel@gmail.com Signed-off-by: Rafael J. Wysocki

cpufreq: Drop policy locking from cpufreq_policy_is_good_for_eas()

2025-05-13T12:27:11Z

Policy locking was added to cpufreq_policy_is_good_for_eas() by commit 4854649b1fb4 ("cpufreq/sched: Move cpufreq-specific EAS checks to cpufreq") to address a theoretical race condition, but it turned out to introduce a circular locking dependency between the policy rwsem and sched_domains_mutex via cpuset_mutex. This leads to a board lockup on OdroidN2 that is based on the ARM64 Amlogic Meson SoC. Drop the policy locking from cpufreq_policy_is_good_for_eas() to address this issue. Fixes: 4854649b1fb4 ("cpufreq/sched: Move cpufreq-specific EAS checks to cpufreq") Closes: https://lore.kernel.org/linux-pm/1bf3df62-0641-459f-99fc-fd511e564b84@samsung.com/ Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2806514.mvXUDI8C0e@rjwysocki.net

cpufreq/sched: Move cpufreq-specific EAS checks to cpufreq

2025-05-07T19:17:56Z

Doing cpufreq-specific EAS checks that require accessing policy internals directly from sched_is_eas_possible() is a bit unfortunate, so introduce cpufreq_ready_for_eas() in cpufreq, move those checks into that new function and make sched_is_eas_possible() call it. While at it, address a possible race between the EAS governor check and governor change by doing the former under the policy rwsem. Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Tested-by: Christian Loehle Reviewed-by: Dietmar Eggemann Link: https://patch.msgid.link/2317800.iZASKD2KPV@rjwysocki.net

Merge back cpufreq material for 6.16

2025-05-04T10:35:42Z