aboutsummaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)AuthorFilesLines
2026-03-27Merge back earlier cpufreq material for 7.1Rafael J. Wysocki4-12/+30
2026-03-25cpufreq: acpi-cpufreq: use DMI max speed when CPPC is unavailableHenry Tseng1-7/+24
On AMD Ryzen Embedded V1780B (Family 17h, Zen 1), the BIOS does not provide ACPI _CPC objects and the CPU does not support MSR-based CPPC (X86_FEATURE_CPPC). The _PSS table only lists nominal P-states (P0 = 3350 MHz), so when get_max_boost_ratio() fails at cppc_get_perf_caps(), cpuinfo_max_freq reports only the base frequency instead of the rated boost frequency (3600 MHz). dmesg: ACPI CPPC: No CPC descriptor for CPU:0 acpi_cpufreq: CPU0: Unable to get performance capabilities (-19) cppc-cpufreq already has a DMI fallback (cppc_get_dmi_max_khz()) that reads the processor max speed from SMBIOS Type 4. Export it and reuse it in acpi-cpufreq as a last-resort source for the boost frequency. A sanity check ensures the DMI value is above the _PSS P0 frequency and within 2x of it; values outside that range are ignored and the existing arch_set_max_freq_ratio() path is taken instead. The 2x upper bound is based on a survey of the AMD Ryzen Embedded V1000 series, where the highest boost-to-base ratio is 1.8x (V1404I: 2.0 GHz base / 3.6 GHz boost). The DMI lookup and sanity check are wrapped in a helper, acpi_cpufreq_resolve_max_freq(), which falls through to arch_set_max_freq_ratio() if the DMI value is absent or out of range. Tested on AMD Ryzen Embedded V1780B with v7.0-rc4: Before: cpuinfo_max_freq = 3350000 (base only) After: cpuinfo_max_freq = 3600000 (includes boost) Link: https://www.amd.com/en/products/embedded/ryzen/ryzen-v1000-series.html#specifications Signed-off-by: Henry Tseng <henrytseng@qnap.com> Link: https://patch.msgid.link/20260324090948.1667340-1-henrytseng@qnap.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-23cpufreq: conservative: Reset requested_freq on limits changeViresh Kumar3-0/+16
A recently reported issue highlighted that the cached requested_freq is not guaranteed to stay in sync with policy->cur. If the platform changes the actual CPU frequency after the governor sets one (e.g. due to platform-specific frequency scaling) and a re-sync occurs later, policy->cur may diverge from requested_freq. This can lead to incorrect behavior in the conservative governor. For example, the governor may assume the CPU is already running at the maximum frequency and skip further increases even though there is still headroom. Avoid this by resetting the cached requested_freq to policy->cur on detecting a change in policy limits. Reported-by: Lifeng Zheng <zhenglifeng1@huawei.com> Tested-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://lore.kernel.org/all/20260210115458.3493646-1-zhenglifeng1@huawei.com/ Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/d846a141a98ac0482f20560fcd7525c0f0ec2f30.1773999467.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-23cpufreq: Don't skip cpufreq_frequency_table_cpuinfo()Viresh Kumar2-6/+7
The commit 6db0f533d320 ("cpufreq: preserve freq_table_sorted across suspend/hibernate") unintentionally made a change where cpufreq_frequency_table_cpuinfo() isn't getting called anymore for old policies getting re-initialized. This leads to potentially invalid values of policy->max and policy->cpuinfo_max_freq. Fix the issue by reverting the original commit and adding the condition for just the sorting function. Fixes: 6db0f533d320 ("cpufreq: preserve freq_table_sorted across suspend/hibernate") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 6.19+ <stable@vger.kernel.org> # 6.19+ Link: https://patch.msgid.link/65ba5c45749267c82e8a87af3dc788b37a0b3f48.1773998611.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-20cpufreq: tegra194: remove COMPILE_TESTRosen Penev1-1/+1
The driver needs architecture specific headers to build. Problem gets exposed when TEGRA_BPMP gets COMPILE_TEST added to it. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-03-17cpufreq: Add QCS8300 to cpufreq-dt-platdev blocklistFaruque Ansari1-0/+1
The Qualcomm QCS8300 platform uses the qcom-cpufreq-hw driver, so add it to the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-03-13cpufreq: ti-cpufreq: Convert to of_machine_get_match()Geert Uytterhoeven1-11/+1
Use the of_machine_get_match() helper instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/bba0631aea78b6db7d453a9f9e98ea16b7e2c269.1772468323.git.geert+renesas@glider.be Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-03-13cpufreq: qcom-nvmem: Convert to of_machine_get_match()Geert Uytterhoeven1-14/+2
Use the of_machine_get_match() helper instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/886a603a7a1de6c8cb14ee0783ee0bceea4d914a.1772468323.git.geert+renesas@glider.be Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-03-13cpufreq: airoha: Convert to of_machine_get_match()Geert Uytterhoeven1-6/+1
Use the of_machine_get_match() helper instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/cc76137755d93af982bf255095adafc7d523692c.1772468323.git.geert+renesas@glider.be Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-03-06cpufreq: governor: Use sysfs_emit() in sysfs show functionsThorsten Blum1-2/+3
Replace sprintf() with sysfs_emit() in sysfs show functions. sysfs_emit() is preferred for formatting sysfs output because it provides safer bounds checking. No functional changes. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260223210351.344388-2-thorsten.blum@linux.dev Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-06cpufreq: intel_pstate: Allow repeated intel_pstate disableFabio M. De Francesco1-1/+1
Repeated intel_pstate disables currently return an error, adding unnecessary complexity to userspace scripts which must first read the current state and conditionally write 'off'. Make repeated intel_pstate disables a no-op. Signed-off-by: Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20260219181600.16388-1-fabio.m.de.francesco@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-05ACPI: CPPC: Move reference performance to capabilitiesPengjie Zhang1-9/+12
Currently, the `Reference Performance` register is read every time the CPU frequency is sampled in `cppc_get_perf_ctrs()`. This function is on the hot path of the cppc_cpufreq driver. Reference Performance indicates the performance level that corresponds to the Reference Counter incrementing and is not expected to change dynamically during runtime (unlike the Delivered and Reference counters). Reading this register in the hot path incurs unnecessary overhead, particularly on platforms where CPC registers are located in the PCC (Platform Communication Channel) subspace. This patch moves `reference_perf` from the dynamic feedback counters structure (`cppc_perf_fb_ctrs`) to the static capabilities structure (`cppc_perf_caps`). Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> [ rjw: Changelog adjustment ] Link: https://patch.msgid.link/20260213100935.19111-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-05cpufreq: Add debug print for current frequency in __cpufreq_driver_target()Pengjie Zhang1-2/+2
Include policy->cur in the debug message to explicitly show the frequency transition (from current to target). Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260129121813.3874516-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-03cpufreq: tegra194: Rename Tegra239 to Tegra238Thierry Reding1-2/+2
This chip identifies as Tegra238, so update the device tree compatible string and data structures associated with it to use the correct name. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-02-27ACPI: CPPC: add APIs and sysfs interface for perf_limitedSumit Gupta1-0/+5
Add sysfs interface to read/write the Performance Limited register. The Performance Limited register indicates to the OS that an unpredictable event (like thermal throttling) has limited processor performance. It contains two sticky bits set by the platform: - Bit 0 (Desired_Excursion): Set when delivered performance is constrained below desired performance. Not used when Autonomous Selection is enabled. - Bit 1 (Minimum_Excursion): Set when delivered performance is constrained below minimum performance. These bits remain set until OSPM explicitly clears them. The write operation accepts a bitmask of bits to clear: - Write 0x1 to clear bit 0 - Write 0x2 to clear bit 1 - Write 0x3 to clear both bits This enables users to detect if platform throttling impacted a workload. Users clear the register before execution, run the workload, then check afterward - if set, hardware throttling occurred during that time window. The interface is exposed as: /sys/devices/system/cpu/cpuX/cpufreq/perf_limited Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-7-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-27cpufreq: cppc: Update MIN_PERF/MAX_PERF in target callbacksSumit Gupta1-1/+40
Update MIN_PERF and MAX_PERF registers from policy->min and policy->max in the .target() and .fast_switch() callbacks. This allows controlling performance bounds via standard scaling_min_freq and scaling_max_freq sysfs interfaces. Similar to intel_cpufreq which updates HWP min/max limits in .target(), cppc_cpufreq now programs MIN_PERF/MAX_PERF along with DESIRED_PERF. Since MIN_PERF/MAX_PERF can be updated even when auto_sel is disabled, they are updated unconditionally. Also program MIN_PERF/MAX_PERF in store_auto_select() when enabling autonomous selection so the platform uses correct bounds immediately. Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Link: https://patch.msgid.link/20260206142658.72583-6-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-27cpufreq: CPPC: Update cached perf_ctrls on sysfs writeSumit Gupta1-2/+29
Update the cached perf_ctrls values when writing via sysfs to keep them in sync with hardware registers: - store_auto_select(): update perf_ctrls.auto_sel - store_energy_performance_preference_val(): update perf_ctrls.energy_perf This ensures consistent cached values after sysfs writes, which complements the cppc_get_perf() initialization during policy setup. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-5-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-27ACPI: CPPC: Add cppc_get_perf() API to read performance controlsSumit Gupta1-0/+6
Add cppc_get_perf() function to read values of performance control registers including desired_perf, min_perf, max_perf, energy_perf, and auto_sel. This provides a read interface to complement the existing cppc_set_perf() write interface for performance control registers. Note that auto_sel is read by cppc_get_perf() but not written by cppc_set_perf() to avoid unintended mode changes during performance updates. It can be updated with existing dedicated cppc_set_auto_sel() API. Use cppc_get_perf() in cppc_cpufreq_get_cpu_data() to initialize perf_ctrls with current hardware register values during cpufreq policy initialization. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20260206142658.72583-2-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-25cpufreq: intel_pstate: Fix crash during turbo disableSrinivas Pandruvada1-5/+5
When the system is booted with kernel command line argument "nosmt" or "maxcpus" to limit the number of CPUs, disabling turbo via: echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo results in a crash: PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI ... RIP: 0010:store_no_turbo+0x100/0x1f0 ... This occurs because for_each_possible_cpu() returns CPUs even if they are not online. For those CPUs, all_cpu_data[] will be NULL. Since commit 973207ae3d7c ("cpufreq: intel_pstate: Rearrange max frequency updates handling code"), all_cpu_data[] is dereferenced even for CPUs which are not online, causing the NULL pointer dereference. To fix that, pass CPU number to intel_pstate_update_max_freq() and use all_cpu_data[] for those CPUs for which there is a valid cpufreq policy. Fixes: 973207ae3d7c ("cpufreq: intel_pstate: Rearrange max frequency updates handling code") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221068 Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 6.16+ <stable@vger.kernel.org> # 6.16+ Link: https://patch.msgid.link/20260225001752.890164-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-24cpufreq: intel_pstate: Fix NULL pointer dereference in update_cpu_qos_request()David Arcari1-1/+3
The update_cpu_qos_request() function attempts to initialize the 'freq' variable by dereferencing 'cpudata' before verifying if the 'policy' is valid. This issue occurs on systems booted with the "nosmt" parameter, where all_cpu_data[cpu] is NULL for the SMT sibling threads. As a result, any call to update_qos_requests() will result in a NULL pointer dereference as the code will attempt to access pstate.turbo_freq using the NULL cpudata pointer. Also, pstate.turbo_freq may be updated by intel_pstate_get_hwp_cap() after initializing the 'freq' variable, so it is better to defer the 'freq' until intel_pstate_get_hwp_cap() has been called. Fix this by deferring the 'freq' assignment until after the policy and driver_data have been validated. Fixes: ae1bdd23b99f ("cpufreq: intel_pstate: Adjust frequency percentage computations") Reported-by: Jirka Hladky <jhladky@redhat.com> Closes: https://lore.kernel.org/all/CAE4VaGDfiPvz3AzrwrwM4kWB3SCkMci25nPO8W1JmTBd=xHzZg@mail.gmail.com/ Signed-off-by: David Arcari <darcari@redhat.com> Cc: 6.18+ <stable@vger.kernel.org> # 6.18+ [ rjw: Added one paragraph to the changelog ] Link: https://patch.msgid.link/20260224122106.228116-1-darcari@redhat.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-21Convert more 'alloc_obj' cases to default GFP_KERNEL argumentsLinus Torvalds5-10/+5
This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21Convert 'alloc_flex' family to use the new default GFP_KERNEL argumentLinus Torvalds1-1/+1
This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds29-38/+38
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook33-52/+49
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-11Merge tag 'devicetree-for-7.0' of ↵Linus Torvalds1-6/+4
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree updates from Rob Herring: "DT core: - Sync dtc/libfdt with upstream v1.7.2-62-ga26ef6400bd8 - Add a for_each_compatible_node_scoped() loop and convert users in cpufreq, dmaengine, clk, cdx, powerpc and Arm - Simplify of/platform.c with scoped loop helpers - Add fw_devlink tracking for "mmc-pwrseq" - Optimize fw_devlink callback code size for pinctrl-N properties - Replace strcmp_suffix() with strends() DT bindings: - Support building single binding targets - Convert google,goldfish-fb, cznic,turris-mox-rwtm, ti,prm-inst - Add bindings for Freescale AVIC, Realtek RTD1xxx system controllers, Microchip 25AA010A EEPROM, OnSemi FIN3385, IEI WT61P803 PUZZLE, Delta Electronics DPS-800-AB power supply, Infineon IR35221 Digital Multi-phase Controller, Infineon PXE1610 Digital Dual Output 6+1 VR12.5 & VR13 CPU Controller, socionext,uniphier-smpctrl, and xlnx,zynqmp-firmware - Lots of trivial binding fixes to address warnings in DTS files. These are mostly for arm64 platforms which is getting closer to be warning free. Some public shaming has helped. - Fix I2C bus node names in examples - Drop obsolete brcm,vulcan-soc binding - Drop unreferenced binding headers" * tag 'devicetree-for-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (60 commits) dt-bindings: interrupt-controller: Add compatiblie string fsl,imx(1|25|27|31|35)-avic dt-bindings: soc: imx: add fsl,aips and fsl,emi compatible strings dt-bindings: display: bridge: lt8912b: Drop reset gpio requirement dt-bindings: firmware: fsl,scu: Mark multi-channel MU layouts as deprecated cpufreq: s5pv210: Simplify with scoped for each OF child loop dmaengine: fsl_raid: Simplify with scoped for each OF child loop clk: imx: imx31: Simplify with scoped for each OF child loop clk: imx: imx27: Simplify with scoped for each OF child loop cdx: Use mutex guard to simplify error handling cdx: Simplify with scoped for each OF child loop powerpc/wii: Simplify with scoped for each OF child loop powerpc/fsp2: Simplify with scoped for each OF child loop ARM: exynos: Simplify with scoped for each OF child loop ARM: at91: Simplify with scoped for each OF child loop of: Add for_each_compatible_node_scoped() helper dt-bindings: Fix emails with spaces or missing brackets scripts/dtc: Update to upstream version v1.7.2-62-ga26ef6400bd8 dt-bindings: crypto: inside-secure,safexcel: Mandate only ring IRQs dt-bindings: crypto: inside-secure,safexcel: Add SoC compatibles of: reserved_mem: Fix placement of __free() annotation ...
2026-02-09Merge tag 'arm64-upstream' of ↵Linus Torvalds1-0/+6
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 updates from Will Deacon: "There's a little less than normal, probably due to LPC & Christmas/New Year meaning that a few series weren't quite ready or reviewed in time. It's still useful across the board, despite the only real feature being support for the LS64 feature enabling 64-byte atomic accesses to endpoints that support it. ACPI: - Add interrupt signalling support to the AGDI handler - Add Catalin and myself to the arm64 ACPI MAINTAINERS entry CPU features: - Drop Kconfig options for PAN and LSE (these are detected at runtime) - Add support for 64-byte single-copy atomic instructions (LS64/LS64V) - Reduce MTE overhead when executing in the kernel on Ampere CPUs - Ensure POR_EL0 value exposed via ptrace is up-to-date - Fix error handling on GCS allocation failure CPU frequency: - Add CPU hotplug support to the FIE setup in the AMU driver Entry code: - Minor optimisations and cleanups to the syscall entry path - Preparatory rework for moving to the generic syscall entry code Hardware errata: - Work around Spectre-BHB on TSV110 processors - Work around broken CMO propagation on some systems with the SI-L1 interconnect Miscellaneous: - Disable branch profiling for arch/arm64/ to avoid issues with noinstr - Minor fixes and cleanups (kexec + ubsan, WARN_ONCE() instead of WARN_ON(), reduction of boolean expression) - Fix custom __READ_ONCE() implementation for LTO builds when operating on non-atomic types Perf and PMUs: - Support for CMN-600AE - Be stricter about supported hardware in the CMN driver - Support for DSU-110 and DSU-120 - Support for the cycles event in the DSU driver (alongside the dedicated cycles counter) - Use IRQF_NO_THREAD instead of IRQF_ONESHOT in the cxlpmu driver - Use !bitmap_empty() as a faster alternative to bitmap_weight() - Fix SPE error handling when failing to resume profiling Selftests: - Add support for the FORCE_TARGETS option to the arm64 kselftests - Avoid nolibc-specific my_syscall() function - Add basic test for the LS64 HWCAP - Extend fp-pidbench to cover additional workload patterns" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (43 commits) perf/arm-cmn: Reject unsupported hardware configurations perf: arm_spe: Properly set hw.state on failures arm64/gcs: Fix error handling in arch_set_shadow_stack_status() arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y arm64: poe: fix stale POR_EL0 values for ptrace kselftest/arm64: Raise default number of loops in fp-pidbench kselftest/arm64: Add a no-SVE loop after SVE in fp-pidbench perf/cxlpmu: Replace IRQF_ONESHOT with IRQF_NO_THREAD arm64: mte: Set TCMA1 whenever MTE is present in the kernel arm64/ptrace: Return early for ptrace_report_syscall_entry() error arm64/ptrace: Split report_syscall() arm64: Remove unused _TIF_WORK_MASK kselftest/arm64: Add missing file in .gitignore arm64: errata: Workaround for SI L1 downstream coherency issue kselftest/arm64: Add HWCAP test for FEAT_LS64 arm64: Add support for FEAT_{LS64, LS64_V} KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1 KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory KVM: arm64: Add documentation for KVM_EXIT_ARM_LDST64B ...
2026-02-03cpufreq: s5pv210: Simplify with scoped for each OF child loopKrzysztof Kozlowski1-6/+4
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Note that there is another part of code using "np" variable, so scoped loop should not shadow it. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260109-of-for-each-compatible-scoped-v3-11-c22fa2c0749a@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-02-03cpufreq: intel_pstate: Enable asym capacity only when CPU SMT is not possibleYaxiong Tian1-1/+1
According to the description in the intel_pstate.rst documentation, Capacity-Aware Scheduling and Energy-Aware Scheduling are only supported on a hybrid processor without SMT. Previously, the system used sched_smt_active() for judgment, which is not a strict condition because users can switch it on or off via /sys at any time. This could lead to incorrect driver settings in certain scenarios. For example, on a CPU that supports SMT, a user can disable SMT via the nosmt parameter to enable asym capacity, and then re-enable SMT via /sys. In such cases, some settings in the driver would no longer be correct. To address this issue, replace sched_smt_active() with cpu_smt_possible(), and only enable asym capacity when CPU SMT is not possible. Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn> [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260203024852.301066-1-tianyaxiong@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28cpufreq: ondemand: Simplify idle cputime granularity testFrederic Weisbecker1-6/+1
cpufreq calls get_cpu_idle_time_us() just to know if idle cputime accounting has a nanoseconds granularity. Use the appropriate indicator instead to make that deduction. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Link: https://patch.msgid.link/aXozx0PXutnm8ECX@localhost.localdomain Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28cpufreq: userspace: make scaling_setspeed return the actual requested frequencyPengjie Zhang1-1/+3
According to the Linux kernel ABI documentation for 'scaling_setspeed': "It returns the last frequency requested by the governor (in kHz) or can be written to in order to set a new frequency for the policy." However, the current implementation of show_speed() returns 'policy->cur'. 'policy->cur' represents the frequency after the driver has resolved the request against the hardware frequency table and applied policy limits (min/max). This creates a discrepancy between the documentation/user expectation and the actual code behavior. For instance: 1. User writes a value to 'scaling_setspeed' that is not in the OPP table (e.g., user asks for A, driver rounds it to B). 2. User reads 'scaling_setspeed'. 3. Code returns B ('policy->cur'). 4. User expects A (the "frequency requested"), but gets B. This patch changes show_speed() to return 'userspace->setspeed', which stores the actual value last requested by the user. This restores the read/write symmetry of the attribute and aligns the code with the ABI description. The effective frequency can still be observed via 'scaling_cur_freq' or 'cpuinfo_cur_freq', preserving the distinction between "what was requested" (setspeed) and "what is effective" (cur_freq). Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: lihuisong@huawei.com Link: https://patch.msgid.link/20260116094623.2980031-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28cpufreq: CPPC: Add generic helpers for sysfs show/storeSumit Gupta1-43/+25
Add generic helper functions for u64 sysfs attributes that follow the common pattern of calling CPPC get/set APIs: - cppc_cpufreq_sysfs_show_u64(): reads value and handles -EOPNOTSUPP - cppc_cpufreq_sysfs_store_u64(): parses input and calls set function Add CPPC_CPUFREQ_ATTR_RW_U64() macro to generate show/store functions using these helpers, reducing boilerplate for simple attributes. Convert auto_act_window and energy_performance_preference_val to use the new macro. No functional changes. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> [ rjw: Retained empty code line after a conditional ] Link: https://patch.msgid.link/20260120145623.2959636-2-sumitg@nvidia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-27Merge tag 'cpufreq-arm-updates-7.0-rc1' of ↵Rafael J. Wysocki6-37/+120
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull CPUFreq Arm updates for 7.0 from Viresh Kumar: "- Update cpufreq-dt-platdev list for tegra, qcom, TI (Aaron Kling, Dhruva Gole, and Konrad Dybcio). - Minor improvements to the cpufreq / cpumask rust implementation (Alexandre Courbot, Alice Ryhl, Tamir Duberstein, and Yilin Chen). - Add support for AM62L3 SoC to ti-cpufreq driver (Dhruva Gole). - Update FIE arch_freq_scale in ticks for non-PCC regs (Jie Zhan). - Other minor cleanups / improvements (Felix Gu, Juan Martinez, Luca Weiss, and Sergey Shtylyov)." * tag 'cpufreq-arm-updates-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: scmi: Fix device_node reference leak in scmi_cpu_domain_id() cpufreq: ti-cpufreq: add support for AM62L3 SoC cpufreq: dt-platdev: Add ti,am62l3 to blocklist cpufreq/amd-pstate: Add comment explaining nominal_perf usage for performance policy cpufreq: scmi: correct SCMI explanation cpufreq: dt-platdev: Block the driver from probing on more QC platforms rust: cpumask: rename methods of Cpumask for clarity and consistency cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regs cpufreq: CPPC: Factor out cppc_fie_kworker_init() ACPI: CPPC: Factor out and export per-cpu cppc_perf_ctrs_in_pcc_cpu() rust: cpufreq: replace `kernel::c_str!` with C-Strings cpufreq: Add Tegra186 and Tegra194 to cpufreq-dt-platdev blocklist dt-bindings: cpufreq: qcom-hw: document Milos CPUFREQ Hardware rust: cpufreq: add __rust_helper to helpers rust: cpufreq: always inline functions using build_assert with arguments
2026-01-27Merge back earlier cpufreq material for 6.20Rafael J. Wysocki4-208/+6
2026-01-27Merge tag 'cpufreq-arm-fixes-6.19-rc8' of ↵Rafael J. Wysocki1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull a CPUFreq driver fix for 6.19 from Viresh Kumar: - Add sentinel to qcom_cpufreq_ipq806x_match_list (Pei Xiao). * tag 'cpufreq-arm-fixes-6.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: qcom-nvmem: add sentinel to qcom_cpufreq_ipq806x_match_list
2026-01-27cpufreq: scmi: Fix device_node reference leak in scmi_cpu_domain_id()Felix Gu1-0/+1
When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In scmi_cpu_domain_id(), it does not release the reference. Fixes: e336baa4193e ("cpufreq: scmi: Prepare to move OF parsing of domain-id to cpufreq") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq: ti-cpufreq: add support for AM62L3 SoCDhruva Gole1-1/+33
Add CPUFreq support for the AM62L3 SoC with the appropriate AM62L3 speed grade constants according to the datasheet [1]. This follows the same architecture-specific implementation pattern as other TI SoCs in the AM6x family. While at it, also sort instances where the SOC family names were not sorted alphabetically. [1] https://www.ti.com/lit/pdf/SPRSPA1 Signed-off-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Kendall Willis <k-willis@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq: dt-platdev: Add ti,am62l3 to blocklistDhruva Gole1-0/+1
Add AM62L3 SoC to the dt-platdev blocklist to ensure proper handling of CPUFreq functionality. The AM62L3 will use its native TI CPUFreq driver implementation instead of the generic dt-platdev driver. This follows the same pattern as other TI SoCs like AM62A7, AM62D2, and AM62P5 which have been previously added to this blocklist. Reviewed-by: Kendall Willis <k-willis@ti.com> Signed-off-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq/amd-pstate: Add comment explaining nominal_perf usage for ↵Juan Martinez1-0/+13
performance policy Add comment explaining why nominal_perf is used for MinPerf when the CPU frequency policy is set to CPUFREQ_POLICY_PERFORMANCE, rather than using highest_perf or lowest_nonlinear_perf. Signed-off-by: Juan Martinez <juan.martinez@amd.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq: scmi: correct SCMI explanationSergey Shtylyov1-1/+1
SCMI stands for System Control and Management Interface, not System Control and Power Interface -- apparently, Sudeep Holla copied this line from his SCPI driver and then just forgot to update the acronym explanation... :-) Fixes: 99d6bdf33877 ("cpufreq: add support for CPU DVFS based on SCMI message protocol") Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq: dt-platdev: Block the driver from probing on more QC platformsKonrad Dybcio1-0/+3
Add a number of QC platforms to the blocklist, they all use either the qcom-cpufreq-hw driver. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regsJie Zhan1-25/+52
Currently, the CPPC Frequency Invariance Engine (FIE) is invoked from the scheduler tick but defers the update of arch_freq_scale to a separate thread because cppc_get_perf_ctrs() would sleep if the CPC regs are in PCC. However, this deferred update mechanism is unnecessary and introduces extra overhead for non-PCC register spaces (e.g. System Memory or FFH), where accessing the regs won't sleep and can be safely performed from the tick context. Furthermore, with the CPPC FIE registered, it throws repeated warnings of "cppc_scale_freq_workfn: failed to read perf counters" on our platform with the CPC regs in System Memory and a power-down idle state enabled. That's because the remote CPU can be in a power-down idle state, and reading its perf counters returns 0. Moving the FIE handling back to the scheduler tick process makes the CPU handle its own perf counters, so it won't be idle and the issue would be inherently solved. To address the above issues, update arch_freq_scale directly in ticks for non-PCC regs and keep the deferred update mechanism for PCC regs. Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq: CPPC: Factor out cppc_fie_kworker_init()Jie Zhan1-12/+17
Factor out the CPPC FIE kworker init in cppc_freq_invariance_init() because it's a standalone procedure for use when the CPC regs are in PCC channels. Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq: qcom-nvmem: add sentinel to qcom_cpufreq_ipq806x_match_listPei Xiao1-0/+1
The of_device_id table is expected to be NULL-terminated. Without the sentinel, the traversal of the array can lead to out-of-bound access, causing undefined behavior. This adds the missing sentinel to the qcom_cpufreq_ipq806x_match_list array. Fixes: 58f5d39d5ed8 ("cpufreq: qcom-nvmem: add compatible fallback for ipq806x for no SMEM") Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27rust: cpufreq: replace `kernel::c_str!` with C-StringsTamir Duberstein1-3/+2
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-27cpufreq: Add Tegra186 and Tegra194 to cpufreq-dt-platdev blocklistAaron Kling1-0/+2
These have platform specific drivers. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-01-08cpufreq: omap: remove driverAndreas Kemnade3-201/+0
The omap-cpufreq driver is not used in the corresponding defconfigs. The pseudo platform device to use it was removed by commit cb6675d6a868 ("ARM: OMAP2+: Remove legacy PM init") 10 years ago. Checking if there is any need to reactivate it: For omap3, dra7 there is ti-cpufreq to create cpufreq-dt device For omap2/4/5 there is cpufreq-dt-plat to create cpufreq-dt device. For omap1 this driver cannot be selected at all. So no users, no need to reactivate the driver somehow. So remove it. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Acked-by: Kevin Hilman <khilman@baylibre.com> Link: https://patch.msgid.link/20260108-omap-cpufreq-removal-v1-1-8fe42f130f48@kemnade.info Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-05cpufreq: Add new helper function returning cpufreq policyLifeng Zheng1-0/+6
cpufreq_cpu_get_raw() gets cpufreq policy only if the CPU is in policy->cpus mask, which means the CPU is already online. But in some cases, the policy is needed before the CPU is added to cpus mask. Add a function to get the policy in these cases. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com> Acked-by: Beata Michalska <beata.michalska@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-12-16cpufreq: dt-platdev: Fix creating device on OPPv1 platformsKrzysztof Kozlowski1-3/+4
Commit 6ea891a6dd37 ("cpufreq: dt-platdev: Simplify with of_machine_get_match_data()") broke several platforms which did not have OPPv2 proprety, because it incorrectly checked for device match data after first matching from "allowlist". Almost all of "allowlist" match entries do not have match data and it is expected to create platform device for them with empty data. Fix this by first checking if platform is on the allowlist with of_machine_device_match() and only then taking the match data. This duplicates the number of checks (we match against the allowlist twice), but makes the code here much smaller. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/CAMuHMdVJD4+J9QpUUs-sX0feKfuPD72CO0dcqN7shvF_UYpZ3Q@mail.gmail.com/ Reported-by: Pavel Pisa <pisa@fel.cvut.cz> Closes: https://lore.kernel.org/all/6hnk7llbwdezh74h74fhvofbx4t4jihel5kvr6qwx2xuxxbjys@rmwbd7lkhrdz/ Fixes: 6ea891a6dd37 ("cpufreq: dt-platdev: Simplify with of_machine_get_match_data()") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Tested-by: Pavel Pisa <pisa@fel.cvut.cz> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20251210051718.132795-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-12-16cpufreq: cpufreq_boost_trigger_state() optimizationLifeng Zheng1-9/+4
Optimize the error handling code in cpufreq_boost_trigger_state(). Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com> [ rjw: Changelog edit ] Link: https://patch.msgid.link/20251202072727.1368285-3-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-16cpufreq: Return -EOPNOTSUPP if no policy supports boostLifeng Zheng1-1/+5
In cpufreq_boost_trigger_state(), if none of the the policies support boost, policy_set_boost() will not be called and this