summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)Author
9 daysMerge back earlier cpufreq material for 6.18Rafael J. Wysocki
10 dayscpufreq: Replace pointer subtraction with iteration macroZihuan Zhang
The cpufreq documentation suggests avoiding direct pointer subtraction when working with entries in driver_freq_table, as it is relatively costly. Instead, the recommended approach is to use the provided iteration macros, like cpufreq_for_each_valid_entry_idx(). Use cpufreq_for_each_entry_idx() instead of pointer subtraction in cpufreq_frequency_table_cpuinfo() which improves code clarity and follows the established cpufreq coding style. While at it, remove redundant local variable initialization from cpufreq_table_index_unsorted(). No functional change intended. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/20250923075553.45532-1-zhangzihuan@kylinos.cn [ rjw: Subject tweak, changelog edits, local variable definition tweak ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
14 dayscpufreq: Initialize cpufreq-based invariance before subsysChristian Loehle
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 <christian.loehle@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-19cpufreq: intel_pstate: Use likely() optimization in intel_pstate_sample()Yaxiong Tian
The comment above the condition `if (cpu->last_sample_time)` clearly indicates that the branch is taken for the vast majority of invocations after the first sample in a cycle. The first sample is a one-time initialization case. Add likely() hint to the condition to improve branch prediction for this performance-critical path in intel_pstate_sample(). Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-19cpufreq: Add defensive check during driver registrationZihuan Zhang
Currently, cpufreq allows drivers to implement both ->target() and ->target_index() callbacks, but that can lead to ambiguous or incorrect behavior. For this reason, prevent cpufreq drivers implementing both ->target() and ->target_index() at the same time from registering. This check can help to catch driver implementation mistakes early and improve overall robustness, without affecting existing valid drivers. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/20250908085738.31602-1-zhangzihuan@kylinos.cn [ rjw: Subject adjustment and changelog rewrite ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-19cpufreq: intel_pstate: Enable HWP without EPP if DEC is enabledRafael J. Wysocki
So far, HWP has never been enabled without EPP (Energy-Performance Preference) interface support, since the lack of the latter indicates an incomplete implementation of HWP, which was the case on early development vehicle platforms. However, HWP can be expected to work if DEC (Dynamic Efficiency Control) is enabled as indicated by setting bit 27 in MSR_IA32_POWER_CTL (DEC enable bit). Accordingly, allow HWP to be enabled if the EPP interface is not supported so long as DEC is enabled in the processor. Still, the EPP control sysfs interface is useless when EPP is not supported, so do not expose it in that case. Link: https://lore.kernel.org/linux-pm/20250904000608.260817-2-srinivas.pandruvada@linux.intel.com/ Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Co-developed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15cpufreq: ACPI: Use on_each_cpu_mask() in drv_write()Rafael J. Wysocki
Make drv_write() call on_each_cpu_mask() instead of using an open-coded equivalent of the latter. Also remove a comment mentioning the smp_call_function_many() usage which is not particularly useful anyway. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-09-15Merge back earlier cpufreq material for 6.18Rafael J. Wysocki
2025-09-11Merge branches 'pm-sleep' and 'pm-em'Rafael J. Wysocki
Merge a hibernation regression fix and an fix related to energy model management for 6.17-rc6 * pm-sleep: PM: hibernate: Restrict GFP mask in hibernation_snapshot() * pm-em: PM: EM: Add function for registering a PD without capacity update
2025-09-10cpufreq: ondemand: Update the efficient idle check for Intel extended FamiliesSohil Mehta
IO time is considered busy by default for modern Intel processors. The current check covers recent Family 6 models but excludes the brand new Families 18 and 19. According to Arjan van de Ven, the model check was mainly due to a lack of testing on systems before INTEL_CORE2_MEROM. He suggests considering all Intel processors as having an efficient idle. Extend the IO busy classification to all Intel processors starting with Family 6, including Family 15 (Pentium 4s) and upcoming Families 18/19. Use an x86 VFM check and move the function to the header file to avoid using arch-specific #ifdefs in the C file. Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> Link: https://patch.msgid.link/20250908230655.2562440-1-sohil.mehta@intel.com [ rjw: Added empty line after #include ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-10cpufreq: conservative: Replace sscanf() with kstrtouint()Kaushlendra Kumar
Replace sscanf() with kstrtouint() in all sysfs store functions to improve input validation and security. The kstrtouint() function provides better error detection, overflow protection, and consistent error handling compared to sscanf(). This maintains existing functionality while improving input validation robustness and following kernel coding best practices for string parsing. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250906115316.3010384-1-kaushlendra.kumar@intel.com [ rjw: Dropped duplicate paragraph from the changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-10PM: EM: Add function for registering a PD without capacity updateRafael J. Wysocki
The intel_pstate driver manages CPU capacity changes itself and it does not need an update of the capacity of all CPUs in the system to be carried out after registering a PD. Moreover, in some configurations (for instance, an SMT-capable hybrid x86 system booted with nosmt in the kernel command line) the em_check_capacity_update() call at the end of em_dev_register_perf_domain() always fails and reschedules itself to run once again in 1 s, so effectively it runs in vain every 1 s forever. To address this, introduce a new variant of em_dev_register_perf_domain(), called em_dev_register_pd_no_update(), that does not invoke em_check_capacity_update(), and make intel_pstate use it instead of the original. Fixes: 7b010f9b9061 ("cpufreq: intel_pstate: EAS support for hybrid platforms") Closes: https://lore.kernel.org/linux-pm/40212796-734c-4140-8a85-854f72b8144d@panix.com/ Reported-by: Kenneth R. Crudup <kenny@panix.com> Tested-by: Kenneth R. Crudup <kenny@panix.com> Cc: 6.16+ <stable@vger.kernel.org> # 6.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-09cpufreq: intel_pstate: Adjust frequency percentage computationsRafael J. Wysocki
Adjust frequency percentage computations in update_cpu_qos_request() to avoid going above the exact numerical percentage in the FREQ_QOS_MAX case. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/3395556.44csPzL39Z@rafael.j.wysocki [ rjw: Rename "cpu" to "cpudata" and "cpunum" to "cpu" ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-09cpufreq: intel_pstate: Rearrange freq QoS updates using __free()Rafael J. Wysocki
Move the code from the for_each_possible_cpu() loop in update_qos_request() to a separate function and use __free() for cpufreq policy reference counting in it to avoid having to call cpufreq_cpu_put() repeatedly (or using goto). While at it, rename update_qos_request() to update_qos_requests() because it updates multiple requests in one go. No intentional functional impact. Link: https://lore.kernel.org/linux-pm/CAJZ5v0gN1T5woSF0tO=TbAh+2-sWzxFjWyDbB7wG2TFCOU01iQ@mail.gmail.com/ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/3026597.e9J7NaK4W3@rafael.j.wysocki [ rjw: Rename "cpu" to "cpudata" and "cpunum" to "cpu" in new code ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-09cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()Rafael J. Wysocki
The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later. Fixes: da5c504c7aae ("cpufreq: intel_pstate: Implement QoS supported freq constraints") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/2255671.irdbgypaU6@rafael.j.wysocki
2025-09-05cpufreq: intel_pstate: Remove EPB-related codeSrinivas Pandruvada
The intel_pstate driver does not enable HWP mode when CPUID.06H:EAX[10] is not set, indicating that EPP (Energy Performance Preference) is not supported by the hardware. When EPP is unavailable, the system falls back to using EPB (Energy Performance Bias) if the feature is supported. However, since the intel_pstate driver will not enable HWP in this scenario, any EPB-related code becomes unreachable and irrelevant. Remove the EPB handling code paths simplifying the driver logic and reducing code size. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20250904000608.260817-1-srinivas.pandruvada@linux.intel.com [ rjw: Subject adjustment ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-05cpufreq: intel_pstate: Rearrange variable declaration involving __free()Rafael J. Wysocki
Follow cleanup.h recommendations and define and assign a variable in one statement when __free() is used. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/2251447.irdbgypaU6@rafael.j.wysocki
2025-09-05cpufreq: core: Rearrange variable declarations involving __free()Rafael J. Wysocki
Follow cleanup.h recommendations and always define and assign variables in one statement when __free() is used. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/4691667.LvFx2qVVIh@rafael.j.wysocki
2025-09-05cpufreq: speedstep-lib: Use int type to store negative error codesQianfeng Rong
Change the return type of the speedstep_get_freqs() function from unsigned int to int because it may return negative error codes. For the same reason, change the 'ret' variables to int type as well. No effect on runtime. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250902114545.651661-4-rongqianfeng@vivo.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-05cpufreq: Use int type to store negative error codesQianfeng Rong
Change the 'ret' variable in store_scaling_setspeed() from unsigned int to int, as it needs to store either negative error codes or zero returned by kstrtouint(). No effect on runtime. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250902114545.651661-2-rongqianfeng@vivo.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-05cpufreq: Drop redundant freq_table parameterZihuan Zhang
Since commit e0b3165ba521 ("cpufreq: add 'freq_table' in struct cpufreq_policy"), freq_table has been stored in struct cpufreq_policy instead of being maintained separately. However, several helpers in freq_table.c still take both policy and freq_table as parameters, even though policy->freq_table can always be used. This leads to redundant function arguments and increases the chance of inconsistencies. This patch removes the unnecessary freq_table argument from these functions and updates their callers to only pass policy. This makes the code simpler, more consistent, and avoids duplication. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250902073323.48330-1-zhangzihuan@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-04Merge tag 'cpufreq-arm-updates-6.18' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Merge CPUFreq updates for 6.18 from Viresh Kumar: "- Minor improvements to Rust Cpumask APIs (Alice Ryhl, Baptiste Lepers, and Shankari Anand). - Minor cleanups and optimizations to various cpufreq drivers (Akhilesh Patil, BowenYu, Dennis Beier, Liao Yuanhong, Zihuan Zhang, Florian Fainelli, Taniya Das, Md Sadre Alam, and Christian Marangi). - Enhancements for TI cpufreq driver (Judith Mendez, and Paresh Bhagat). - Enhancements for mediatek cpufreq driver (Nicolas Frattaroli). - Remove outdated cpufreq-dt.txt (Frank Li). - Update MAINTAINERS for virtual-cpufreq maintainer (Saravana Kannan)." * tag 'cpufreq-arm-updates-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: (28 commits) cpufreq: mediatek: avoid redundant conditions cpufreq/longhaul: handle NULL policy in longhaul_exit cpufreq: tegra186: Use scope-based cleanup helper cpufreq: mediatek: Use scope-based cleanup helper cpufreq: s5pv210: Use scope-based cleanup helper cpufreq: CPPC: Use scope-based cleanup helper cpufreq: brcmstb-avs: Use scope-based cleanup helper dt-bindings: Remove outdated cpufreq-dt.txt arm64: dts: ti: k3-am62p: Fix supported hardware for 1GHz OPP cpufreq: ti: Allow all silicon revisions to support OPPs cpufreq: ti: Support more speed grades on AM62Px SoC cpufreq: ti: Add support for AM62D2 cpufreq: dt-platdev: Blacklist ti,am62d2 SoC rust: opp: update ARef and AlwaysRefCounted imports from sync::aref cpufreq: mediatek-hw: don't use error path on NULL fdvfs cpufreq: scmi: Account for malformed DT in scmi_dev_used_by_cpus() rust: cpumask: Mark CpumaskVar as transparent rust: cpumask: rename CpumaskVar::as[_mut]_ref to from_raw[_mut] dt-bindings: cpufreq: cpufreq-qcom-hw: Add QCS615 compatible MAINTAINERS: Add myself as virtual-cpufreq maintainer ...
2025-09-04cpufreq: mediatek: avoid redundant conditionsLiao Yuanhong
While 'if (i <= 0) ... else if (i > 0) ...' is technically equivalent to 'if (i <= 0) ... else ...', the latter is vastly easier to read because it avoids writing out a condition that is unnecessary. Let's drop such unnecessary conditions. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-09-03cpufreq/amd-pstate: Fix a regression leading to EPP 0 after resumeMario Limonciello (AMD)
During the suspend sequence the cached CPPC request is destroyed with the expectation that it's restored during resume. This assumption broke when the separate cache EPP variable was removed, and then it was broken again by commit 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option") which explicitly set it to zero during suspend. Remove the invalidation and set the value during the suspend call to update limits so that the cached variable can be used to restore on resume. Fixes: 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option") Fixes: b7a41156588a ("cpufreq/amd-pstate: Invalidate cppc_req_cached during suspend") Reported-by: goldens <goldenspinach.rhbugzilla@gmail.com> Closes: https://community.frame.work/t/increased-power-usage-after-resuming-from-suspend-on-ryzen-7040-kernel-6-15-regression/ Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2391221 Tested-by: goldens <goldenspinach.rhbugzilla@gmail.com> Tested-by: Willian Wang <kernel@willian.wang> Reported-by: Vincent Mauirn <vincent.maurin.fr@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219981 Tested-by: Alex De Lorenzo <kernel@alexdelorenzo.dev> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20250826052747.2240670-1-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-09-01cpufreq/longhaul: handle NULL policy in longhaul_exitDennis Beier
longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic. This patch adds a check using unlikely() and returns early if the policy is NULL. Bugzilla: #219962 Signed-off-by: Dennis Beier <nanovim@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-29cpufreq: tegra186: Use scope-based cleanup helperZihuan Zhang
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy) annotation for policy references. This reduces the risk of reference counting mistakes and aligns the code with the latest kernel style. No functional change intended. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> [ Viresh: Minor changes ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-29cpufreq: mediatek: Use scope-based cleanup helperZihuan Zhang
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy) annotation for policy references. This reduces the risk of reference counting mistakes and aligns the code with the latest kernel style. No functional change intended. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> [ Viresh: Minor changes ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-29cpufreq: s5pv210: Use scope-based cleanup helperZihuan Zhang
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy) annotation for policy references. This reduces the risk of reference counting mistakes and aligns the code with the latest kernel style. No functional change intended. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> [ Viresh: Minor changes ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-29cpufreq: CPPC: Use scope-based cleanup helperZihuan Zhang
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy) annotation for policy references. This reduces the risk of reference counting mistakes and aligns the code with the latest kernel style. No functional change intended. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> [ Viresh: Minor changes ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-29cpufreq: brcmstb-avs: Use scope-based cleanup helperZihuan Zhang
Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy) annotation for policy references. This reduces the risk of reference counting mistakes and aligns the code with the latest kernel style. No functional change intended. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> [ Viresh: Minor changes to commit log ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-22cpufreq: simplify setpolicy/target check in driver verificationZihuan Zhang
cpufreq drivers are supposed to use either ->setpolicy() or ->target()/->target_index(). Simplify the existing check by collapsing it into a single boolean expression: (!!driver->setpolicy == (driver->target_index || driver->target)) This is a readability/maintainability cleanup and keeps the semantics unchanged. No functional change intended. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250822070424.166795-3-zhangzihuan@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-08-22cpufreq: use strlen() for governor name comparisonZihuan Zhang
Most kernel code using strncasecmp()/strncmp() passes strlen("xxx") as the length argument. cpufreq_parse_policy() previously used CPUFREQ_NAME_LEN (16), which is longer than the actual strings ("performance" is 11 chars, "powersave" is 9 chars). This patch switches to strlen() for the comparison, making the matching slightly more permissive (e.g., "powersavexxx" will now also match "powersave"). While this is unlikely to cause functional issues, it aligns cpufreq with common kernel style and makes the behavior more intuitive. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250822070424.166795-2-zhangzihuan@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-08-22cpufreq: ti: Allow all silicon revisions to support OPPsJudith Mendez
More silicon revisions are being defined for AM62x, AM62Px, and AM62ax SoCs. These silicon may also support currently establishes OPPs, so remove the revision limitation in ti-cpufreq and thus determine if an OPP applies with speed grade efuse parsing. Signed-off-by: Judith Mendez <jm@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-22cpufreq: ti: Support more speed grades on AM62Px SoCJudith Mendez
As the AM62Px SoC family matures more speed grades are being defined. Add support for speed grades U and T which both support all currently established OPPs. Signed-off-by: Judith Mendez <jm@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-21cpufreq/amd-pstate: Fix setting of CPPC.min_perf in active mode for ↵Gautham R. Shenoy
performance governor In the "active" mode of the amd-pstate driver with performance governor, the CPPC.min_perf is expected to be the nominal_perf. However after commit a9b9b4c2a4cd ("cpufreq/amd-pstate: Drop min and max cached frequencies"), this is not the case when the governor is switched from performance to powersave and back to performance, and the CPPC.min_perf will be equal to the scaling_min_freq that was set for the powersave governor. This is because prior to commit a9b9b4c2a4cd ("cpufreq/amd-pstate: Drop min and max cached frequencies"), amd_pstate_epp_update_limit() would unconditionally call amd_pstate_update_min_max_limit() and the latter function would enforce the CPPC.min_perf constraint when the governor is performance. However, after the aforementioned commit, amd_pstate_update_min_max_limit() is called by amd_pstate_epp_update_limit() only when either the scaling_{min/max}_freq is different from the cached value of cpudata->{min/max}_limit_freq, which wouldn't have changed on a governor transition from powersave to performance, thus missing out on enforcing the CPPC.min_perf constraint for the performance governor. Fix this by invoking amd_pstate_epp_udpate_limit() not only when the {min/max} limits have changed from the cached values, but also when the policy itself has changed. Fixes: a9b9b4c2a4cd ("cpufreq/amd-pstate: Drop min and max cached frequencies") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250821042638.356-1-gautham.shenoy@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-08-20cpufreq: ti: Add support for AM62D2Paresh Bhagat
Add support for TI K3 AM62D2 SoC to read speed and revision values from hardware and pass to OPP layer. AM62D shares the same configuations as AM62A so use existing am62a7_soc_data. Signed-off-by: Paresh Bhagat <p-bhagat@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-20cpufreq: dt-platdev: Blacklist ti,am62d2 SoCParesh Bhagat
Add ti,am62d2 SoC to the blacklist as the ti-cpufreq driver will handle creating the cpufreq-dt platform device after it completes and ensure it is not created twice. Signed-off-by: Paresh Bhagat <p-bhagat@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-20cpufreq: mediatek-hw: don't use error path on NULL fdvfsNicolas Frattaroli
The IS_ERR_OR_NULL check for priv->fdvfs is inappropriate, and should be an IS_ERR check instead, as a NULL value here would propagate it to PTR_ERR. In practice, there is no problem here, as devm_of_iomap cannot return NULL in any circumstance. However, it causes a Smatch static checker warning. Fix the warning by changing the check from IS_ERR_OR_NULL to IS_ERR. Fixes: 32e0d669f3ac ("cpufreq: mediatek-hw: Add support for MT8196") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-pm/aKQubSEXH1TXQpnR@stanley.mountain/ Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-19cpufreq: Avoid calling get_governor() for first policyZihuan Zhang
When a cpufreq driver registers the first policy, it may attempt to initialize the policy governor from `last_governor`. However, this is meaningless for the first policy instance, because `last_governor` is only updated when policies are removed (e.g. during CPU offline). The `last_governor` mechanism is intended to restore the previously used governor across CPU hotplug events. For the very first policy, there is no "previous governor" to restore, so calling get_governor(last_governor) is unnecessary and potentially confusing. Skip looking up `last_governor` when registering the first policy. Instead, it directly uses the default governor after all governors have been registered and are available. This avoids meaningless lookups, reduces unnecessary module reference handling, and simplifies the initial policy path. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250725041450.68754-1-zhangzihuan@kylinos.cn [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-08-19cpufreq: scmi: Account for malformed DT in scmi_dev_used_by_cpus()Florian Fainelli
Broadcom STB platforms were early adopters (2017) of the SCMI framework and as a result, not all deployed systems have a Device Tree entry where SCMI protocol 0x13 (PERFORMANCE) is declared as a clock provider, nor are the CPU Device Tree node(s) referencing protocol 0x13 as their clock provider. This was clarified in commit e11c480b6df1 ("dt-bindings: firmware: arm,scmi: Extend bindings for protocol@13") in 2023. For those platforms, we allow the checks done by scmi_dev_used_by_cpus() to continue, and in the event of not having done an early return, we key off the documented compatible string and give them a pass to continue to use scmi-cpufreq. Fixes: 6c9bb8692272 ("cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-11cpufreq: intel_pstate: Support Clearwater Forest OOB modeSrinivas Pandruvada
Prevent intel_pstate from loading when OOB (Out Of Band) P-states mode is enabled. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20250808145122.4057208-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-08-11cpufreq: qcom-nvmem: Enable cpufreq for ipq5424Md Sadre Alam
IPQ5424 have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon. Added support for ipq5424 on nvmem driver which helps to determine OPPs at runtime based on the eFuse register which has the CPU frequency limits. opp-supported-hw dt binding can be used to indicate the available OPPs for each limit. nvmem driver also creates the "cpufreq-dt" platform_device after passing the version matching data to the OPP framework so that the cpufreq-dt handles the actual cpufreq implementation. Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> [ Changed '!=' based check to '==' based check ] Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-11cpufreq: Remove unused parameter in cppc_perf_from_fbctrs()BowenYu
Remove the unused parameter cppc_cpudata* cpu_data in cppc_perf_from_fbctrs(). Signed-off-by: BowenYu <yubowen8@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-11cpufreq: armada-37xx: use max() to calculate target_vmAkhilesh Patil
Use max() macro while calculating target_vm to simplify and improve the armada-37xx-cpufreq driver code. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202503251256.rrl65HgY-lkp@intel.com/ Reported-by: Yang Ruibin <11162571@vivo.com> Closes: https://lore.kernel.org/lkml/2c55fb07-b29e-43e0-8697-f75d1f0df89a@vivo.com/ Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-11cpufreq: airoha: Add support for AN7583 SoCChristian Marangi
New Airoha AN7583 SoC use the same exact logic to control the CPU frequency. Add the Device compatible to the block list for cpufreq-dt-plat and to the Airoha CPUFreq driver compatible list. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-11cpufreq: mediatek-hw: Add support for MT8196Nicolas Frattaroli
The MT8196 SoC uses DVFS to set a desired target frequency for each CPU core. It also uses slightly different register offsets. Add support for it, which necessitates reworking how the mmio regs are acquired, as mt8196 has the fdvfs register before the performance domain registers. I've verified with both `sysbench cpu run` and `head -c 10G \ /dev/urandom | pigz -p 8 -c - | pv -ba > /dev/null` that we don't just get a higher reported clock frequency, but that the observed performance also increases, by a factor of 2.64 in an 8 thread sysbench test. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogiaocchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-11cpufreq: mediatek-hw: Separate per-domain and per-instance dataNicolas Frattaroli
As it stood, the mediatek cpufreq driver could get away with never really having a private driver instance struct. This is because all data was stored in the per-domain structs. However, this complicates matters when actual per-instance data like the variant struct is introduced. Instead of having a pointer to it for every domain, have a pointer to a global "priv" struct that can be extended over time, and rename the "data" struct to "domain" to distinguish its purpose better. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-11cpufreq: mediatek-hw: Refactor match data into structNicolas Frattaroli
While the driver could get away with having the per-compatible match data just be an array of the reg offsets, the only thing it used it for right now, this doesn't really allow it to be extended in any meaningful way if some other per-variant information needs to be communicated. In preparation of adding support for hybrid "FDVFS" for MT8196, refactor the code to make the DT match data a struct, which currently only contains a single member: the reg offsets. This will allow this struct to be extended with other members for other hardware variants. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-08-03Merge tag 'rust-6.17' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust updates from Miguel Ojeda: "Toolchain and infrastructure: - Enable a set of Clippy lints: 'ptr_as_ptr', 'ptr_cast_constness', 'as_ptr_cast_mut', 'as_underscore', 'cast_lossless' and 'ref_as_ptr' These are intended to avoid type casts with the 'as' operator, which are quite powerful, into restricted variants that are less powerful and thus should help to avoid mistakes - Remove the 'author' key now that most instances were moved to the plural one in the previous cycle 'kernel' crate: - New 'bug' module: add 'warn_on!' macro which reuses the existing 'BUG'/'WARN' infrastructure, i.e. it respects the usual sysctls and kernel parameters: warn_on!(value == 42); To avoid duplicating the assembly code, the same strategy is followed as for the static branch code in order to share the assembly between both C and Rust This required a few rearrangements on C arch headers -- the existing C macros should still generate the same outputs, thus no functional change expected there - 'workqueue' module: add delayed work items, including a 'DelayedWork' struct, a 'impl_has_delayed_work!' macro and an 'enqueue_delayed' method, e.g.: /// Enqueue the struct for execution on the system workqueue, /// where its value will be printed 42 jiffies later. fn print_later(value: Arc<MyStruct>) { let _ = workqueue::system().enqueue_delayed(value, 42); } - New 'bits' module: add support for 'bit' and 'genmask' functions, with runtime- and compile-time variants, e.g.: static_assert!(0b00010000 == bit_u8(4)); static_assert!(0b00011110 == genmask_u8(1..=4)); assert!(checked_bit_u32(u32::BITS).is_none()); - 'uaccess' module: add 'UserSliceReader::strcpy_into_buf', which reads NUL-terminated strings from userspace into a '&CStr' Introduce 'UserPtr' newtype, similar in purpose to '__user' in C, to minimize mistakes handling userspace pointers, including mixing them up with integers and leaking them via the 'Debug' trait. Add it to the prelude, too - Start preparations for the replacement of our custom 'CStr' type with the analogous type in the 'core' standard library. This will take place across several cycles to make it easier. For this one, it includes a new 'fmt' module, using upstream method names and some other cleanups Replace 'fmt!' with a re-export, which helps Clippy lint properly, and clean up the found 'uninlined-format-args' instances - 'dma' module: - Clarify wording and be consistent in 'coherent' nomenclature - Convert the 'read!()' and 'write!()' macros to return a 'Result' - Add 'as_slice()', 'write()' methods in 'CoherentAllocation' - Expose 'count()' and 'size()' in 'CoherentAllocation' and add the corresponding type invariants - Implement 'CoherentAllocation::dma_handle_with_offset()' - 'time' module: - Make 'Instant' generic over clock source. This allows the compiler to assert that arithmetic expressions involving the 'Instant' use 'Instants' based on the same clock source - Make 'HrTimer' generic over the timer mode. 'HrTimer' timers take a 'Duration' or an 'Instant' when setting the expiry time, depending on the timer mode. With this change, the compiler can check the type matches the timer mode - Add an abstraction for 'fsleep'. 'fsleep' is a flexible sleep function that will select an appropriate sleep method depending on the requested sleep time - Avoid 64-bit divisions on 32-bit hardware when calculating timestamps - Seal the 'HrTimerMode' trait. This prevents users of the 'HrTimerMode' from implementing the trait on their own types - Pass the correct timer mode ID to 'hrtimer_start_range_ns()' - 'list' module: remove 'OFFSET' constants, allowing to remove pointer arithmetic; now 'impl_list_item!' invokes 'impl_has_list_links!' or 'impl_has_list_links_self_ptr!'. Other simplifications too - 'types' module: remove 'ForeignOwnable::PointedTo' in favor of a constant, which avoids exposing the type of the opaque pointer, and require 'into_foreign' to return non-null Remove the 'Either<L, R>' type as well. It is unused, and we want to encourage the use of custom enums for concrete use cases - 'sync' module: implement 'Borrow' and 'BorrowMut' for 'Arc' types to allow them to be used in generic APIs - 'alloc' module: implement 'Borrow' and 'BorrowMut' for 'Box<T, A>'; and 'Borrow', 'BorrowMut' and 'Default' for 'Vec<T, A>' - 'Opaque' type: add 'cast_from' method to perform a restricted cast that cannot change the inner type and use it in callers of 'container_of!'. Rename 'raw_get' to 'cast_into' to match it - 'rbtree' module: add 'is_empty' method - 'sync' module: new 'aref' submodule to hold 'AlwaysRefCounted' and 'ARef', which are moved from the too general 'types' module which we want to reduce or eventually remove. Also fix a safety comment in 'static_lock_class' 'pin-init' crate: - Add 'impl<T, E> [Pin]Init<T, E> for Result<T, E>', so results are now (pin-)initializers - Add 'Zeroable::init_zeroed()' that delegates to 'init_zeroed()' - New 'zeroed()', a safe version of 'mem::zeroed()' and also provide it via 'Zeroable::zeroed()' - Implement 'Zeroable' for 'Option<&T>', 'Option<&mut T>' and for 'Option<[unsafe] [extern "abi"] fn(...args...) -> ret>' for '"Rust"' and '"C"' ABIs and up to 20 arguments - Changed blanket impls of 'Init' and 'PinInit' from 'impl<T, E> [Pin]Init<T, E> for T' to 'impl<T> [Pin]Init<T> for T' - Renamed 'zeroed()' to 'init_zeroed()' - Upstream dev news: improve CI more to deny warnings, use '--all-targets'. Check the synchronization status of the two '-next' branches in upstream and the kernel MAINTAINERS: - Add Vlastimil Babka, Liam R. Howlett, Uladzislau Rezki and Lorenzo Stoakes as reviewers (thanks everyone) And a few other cleanups and improvements" * tag 'rust-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (76 commits) rust: Add warn_on macro arm64/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with Rust riscv/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with Rust x86/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with Rust rust: kernel: move ARef and AlwaysRefCounted to sync::aref rust: sync: fix safety comment for `static_lock_class` rust: types: remove `Either<L, R>` rust: kernel: use `core::ffi::CStr` method names rust: str: add `CStr` methods matching `core::ffi::CStr` rust: str: remove unnecessary qualification rust: use `kernel::{fmt,prelude::fmt!}` rust: kernel: add `fmt` module rust: kernel: remove `fmt!`, fix clippy::uninlined-format-args scripts: rust: emit path candidates in panic message scripts: rust: replace length checks with match rust: list: remove nonexistent generic parameter in link rust: bits: add support for bits/genmask macros rust: list: remove OFFSET constants rust: list: add `impl_list_item!` examples rust: list: use fully qualified path ...
2025-07-30Merge tag 'trace-unused-v6.17' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracepoint cleanup from Steven Rostedt: "Remove or hide unused tracepoints Tracepoints take up memory (around 5K per tracepoint) even when they are unused. Changes are being made to detect when a tracepoint is defined but unused and a warning is shown at build. But those changes are not yet ready for inclusion. - Fix some of the unused tracepoints that it detected Some tracepoints were removed and others were hidden by config settings to match the config settings of where they are instantiated. Some tracepoints were moved into architecture specific code as only one architecture used them. - Call the ftrace_test_filter tracepoint in an unreachable if statement The ftrace_test_filter tracepoint which is defined when ftrace selftests are configured and is used to test the filter logic, but the tracepoint is not actually called. It is put into an if statement to not have it get compiled out, but also not warn for not being used" * tag 'trace-unused-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: sched: Hide numa events under CONFIG_NUMA_BALANCING powerpc/thp: tracing: Hide hugepage events under CONFIG_PPC_BOOK3S_64 tracing: Call trace_ftrace_test_filter() for the event tracing: arm: arm64: Hide trace events ipi_raise, ipi_entry and ipi_exit binder: Remove unused binder lock events PM: tracing: Hide power_domain_target event under ARCH_OMAP2PLUS PM: tracing: Hide device_pm_callback events under PM_SLEEP PM: tracing: Hide psci_domain_idle events under ARM_PSCI_CPUIDLE PM: cpufreq: powernv/tracing: Move powernv_throttle trace event alarmtimer: Hide alarmtimer_suspend event when RTC_CLASS is not configured tracing, AER: Hide PCIe AER event when PCIEAER is not configured