summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)Author
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
2025-07-29Merge tag 'x86-platform-2025-07-29' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 platform updates from Ingo Molnar: "This adds support for the AMD hardware feedback interface (HFI), by Perry Yuan" * tag 'x86-platform-2025-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/itmt: Add debugfs file to show core priorities platform/x86/amd: hfi: Add debugfs support platform/x86/amd: hfi: Set ITMT priority from ranking data cpufreq/amd-pstate: Disable preferred cores on designs with workload classification x86/process: Clear hardware feedback history for AMD processors platform/x86: hfi: Add power management callback platform/x86: hfi: Add online and offline callback support platform/x86: hfi: Init per-cpu scores for each class platform/x86: hfi: Parse CPU core ranking data from shared memory platform/x86: hfi: Introduce AMD Hardware Feedback Interface Driver x86/msr-index: Add AMD workload classification MSRs MAINTAINERS: Add maintainer entry for AMD Hardware Feedback Driver Documentation/x86: Add AMD Hardware Feedback Interface documentation
2025-07-29Merge tag 'driver-core-6.17-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core updates from Danilo Krummrich: "debugfs: - Remove unneeded debugfs_file_{get,put}() instances - Remove last remnants of debugfs_real_fops() - Allow storing non-const void * in struct debugfs_inode_info::aux sysfs: - Switch back to attribute_group::bin_attrs (treewide) - Switch back to bin_attribute::read()/write() (treewide) - Constify internal references to 'struct bin_attribute' Support cache-ids for device-tree systems: - Add arch hook arch_compact_of_hwid() - Use arch_compact_of_hwid() to compact MPIDR values on arm64 Rust: - Device: - Introduce CoreInternal device context (for bus internal methods) - Provide generic drvdata accessors for bus devices - Provide Driver::unbind() callbacks - Use the infrastructure above for auxiliary, PCI and platform - Implement Device::as_bound() - Rename Device::as_ref() to Device::from_raw() (treewide) - Implement fwnode and device property abstractions - Implement example usage in the Rust platform sample driver - Devres: - Remove the inner reference count (Arc) and use pin-init instead - Replace Devres::new_foreign_owned() with devres::register() - Require T to be Send in Devres<T> - Initialize the data kept inside a Devres last - Provide an accessor for the Devres associated Device - Device ID: - Add support for ACPI device IDs and driver match tables - Split up generic device ID infrastructure - Use generic device ID infrastructure in net::phy - DMA: - Implement the dma::Device trait - Add DMA mask accessors to dma::Device - Implement dma::Device for PCI and platform devices - Use DMA masks from the DMA sample module - I/O: - Implement abstraction for resource regions (struct resource) - Implement resource-based ioremap() abstractions - Provide platform device accessors for I/O (remap) requests - Misc: - Support fallible PinInit types in Revocable - Implement Wrapper<T> for Opaque<T> - Merge pin-init blanket dependencies (for Devres) Misc: - Fix OF node leak in auxiliary_device_create() - Use util macros in device property iterators - Improve kobject sample code - Add device_link_test() for testing device link flags - Fix typo in Documentation/ABI/testing/sysfs-kernel-address_bits - Hint to prefer container_of_const() over container_of()" * tag 'driver-core-6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: (84 commits) rust: io: fix broken intra-doc links to `platform::Device` rust: io: fix broken intra-doc link to missing `flags` module rust: io: mem: enable IoRequest doc-tests rust: platform: add resource accessors rust: io: mem: add a generic iomem abstraction rust: io: add resource abstraction rust: samples: dma: set DMA mask rust: platform: implement the `dma::Device` trait rust: pci: implement the `dma::Device` trait rust: dma: add DMA addressing capabilities rust: dma: implement `dma::Device` trait rust: net::phy Change module_phy_driver macro to use module_device_table macro rust: net::phy represent DeviceId as transparent wrapper over mdio_device_id rust: device_id: split out index support into a separate trait device: rust: rename Device::as_ref() to Device::from_raw() arm64: cacheinfo: Provide helper to compress MPIDR value into u32 cacheinfo: Add arch hook to compress CPU h/w id into 32 bits for cache-id cacheinfo: Set cache 'id' based on DT data container_of: Document container_of() is not to be used in new code driver core: auxiliary bus: fix OF node leak ...
2025-07-22cpufreq: CPPC: Mark driver with NEED_UPDATE_LIMITS flagPrashant Malani
AMU counters on certain CPPC-based platforms tend to yield inaccurate delivered performance measurements on systems that are idle/mostly idle. This results in an inaccurate frequency being stored by cpufreq in its policy structure when the CPU is brought online. [1] Consequently, if the userspace governor tries to set the frequency to a new value, there is a possibility that it would be the erroneous value stored earlier. In such a scenario, cpufreq would assume that the requested frequency has already been set and return early, resulting in the correct/new frequency request never making it to the hardware. Since the operating frequency is liable to this sort of inconsistency, mark the CPPC driver with CPUFREQ_NEED_UPDATE_LIMITS so that it is always invoked when a target frequency update is requested. Link: https://lore.kernel.org/linux-pm/20250619000925.415528-3-pmalani@google.com/ [1] Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Prashant Malani <pmalani@google.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20250722055611.130574-2-pmalani@google.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-21PM: cpufreq: powernv/tracing: Move powernv_throttle trace eventSteven Rostedt
As the trace event powernv_throttle is only used by the powernv code, move it to a separate include file and have that code directly enable it. Trace events can take up around 5K of memory when they are defined regardless if they are used or not. It wastes memory to have them defined in configurations where the tracepoint is not used. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/20250612145407.906308844@goodmis.org Fixes: 0306e481d479a ("cpufreq: powernv/tracing: Add powernv_throttle tracepoint") Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-21Merge tag 'cpufreq-arm-updates-6.17' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Merge CPUFreq updates for 6.17 from Viresh Kumar: "- tegra124: Allow building as a module (Aaron Kling). - Minor cleanups for Rust cpufreq and cpumask APIs and fix MAINTAINERS entry for cpu.rs (Abhinav Ananthu, Ritvik Gupta, and Lukas Bulwahn). - Minor cleanups for miscellaneous cpufreq drivers (Arnd Bergmann, Dan Carpenter, Krzysztof Kozlowski, Sven Peter, and Svyatoslav Ryhel)." * tag 'cpufreq-arm-updates-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: drivers: cpufreq: add Tegra114 support rust: cpumask: Replace `MaybeUninit` and `mem::zeroed` with `Opaque` APIs cpufreq: tegra124: Allow building as a module cpufreq: dt: Add register helper cpufreq: Export disable_cpufreq() cpufreq: armada-8k: Fix off by one in armada_8k_cpufreq_free_table() cpufreq: armada-8k: make both cpu masks static rust: cpufreq: use c_ types from kernel prelude rust: cpufreq: Ensure C ABI compatibility in all unsafe cpufreq: brcmstb-avs: Fully open-code compatible for grepping cpufreq: apple: drop default ARCH_APPLE in Kconfig MAINTAINERS: adjust file entry in CPU HOTPLUG
2025-07-21rust: kernel: remove `fmt!`, fix clippy::uninlined-format-argsTamir Duberstein
Rather than export a macro that delegates to `core::format_args`, simply re-export `core::format_args` as `fmt` from the prelude. This exposes clippy warnings which were previously obscured by this macro, such as: warning: variables can be used directly in the `format!` string --> ../drivers/cpufreq/rcpufreq_dt.rs:21:43 | 21 | let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?; | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]` help: change this to | 21 - let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?; 21 + let prop_name = CString::try_from_fmt(fmt!("{name}-supply")).ok()?; | Thus fix them in the same commit. This could possibly be fixed in two stages, but the diff is small enough (outside of kernel/str.rs) that I hope it can be taken in a single commit. Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-1-a91524037783@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-07-15drivers: cpufreq: add Tegra114 supportSvyatoslav Ryhel
Tegra114 is fully compatible with existing Tegra124 cpufreq driver. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-07-14cpufreq: Exit governor when failed to start old governorLifeng Zheng
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 <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-5-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Move the check of cpufreq_driver->get into ↵Lifeng Zheng
cpufreq_verify_current_freq() Move the check of cpufreq_driver->get into cpufreq_verify_current_freq() in case of calling it without check. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-4-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Init policy->rwsem before it may be possibly usedLifeng Zheng
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 <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-3-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Initialize cpufreq-based frequency-invariance laterLifeng Zheng
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 <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-2-zhenglifeng1@huawei.com [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Remove duplicate check in __cpufreq_offline()Lifeng Zheng
The has_target() checks in __cpufreq_offline() are duplicate. Remove one of them and put the operations of exiting governor together with storing last governor's name. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250623133402.3120230-5-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Contain scaling_cur_freq.attr in cpufreq_attrsLifeng Zheng
After commit c034b02e213d ("cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers"), the file scaling_cur_freq is exposed to all drivers. No need to create this file separately. It's better to be contained in cpufreq_attrs. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250623133402.3120230-4-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: intel_pstate: Add Granite Rapids support in no-HWP modeLi RongQing
Users may disable HWP in firmware, in which case intel_pstate wouldn't load unless the CPU model is explicitly supported. Signed-off-by: Li RongQing <lirongqing@baidu.com> Link: https://patch.msgid.link/20250623105601.3924-1-lirongqing@baidu.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive modeRafael J. Wysocki
In the passive mode, intel_cpufreq_update_pstate() sets HWP_MIN_PERF in accordance with the target frequency to ensure delivering adequate performance, but it sets HWP_DESIRED_PERF to 0, so the processor has no indication that the desired performance level is actually equal to the floor one. This may cause it to choose a performance point way above the desired level. Moreover, this is inconsistent with intel_cpufreq_adjust_perf() which actually sets HWP_DESIRED_PERF in accordance with the target performance value. Address this by adjusting intel_cpufreq_update_pstate() to pass target_pstate as both the minimum and the desired performance levels to intel_cpufreq_hwp_update(). Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Shashank Balaji <shashank.mahadasyam@sony.com> Link: https://patch.msgid.link/6173276.lOV4Wx5bFT@rjwysocki.net
2025-07-09cpufreq: tegra124: Allow building as a moduleAaron Kling
This requires four changes: * Using the cpufreq-dt register helper to establish a hard dependency for depmod to track * Adding a remove routine to remove the cpufreq-dt device * Adding a exit routine to handle cleaning up the driver * Populating module license Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-07-09cpufreq: dt: Add register helperAaron Kling
Cpufreq-dt currently exports no functions. This means that drivers that are based on cpufreq-dt have no way of establishing a depmod dependency on it. This helper allows that link. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-07-09cpufreq: Export disable_cpufreq()Aaron Kling
This is used by the tegra124-cpufreq driver. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-07-07cpufreq/amd-pstate: Disable preferred cores on designs with workload ↵Mario Limonciello
classification On designs that have workload classification, it's preferred that the amd-hfi driver is used to provide hints to the scheduler of which cores to use instead of the amd-pstate driver. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/20250609200518.3616080-11-superm1@kernel.org
2025-07-02cpufreq: armada-8k: Fix off by one in armada_8k_cpufreq_free_table()Dan Carpenter
The freq_tables[] array has num_possible_cpus() elements so, to avoid an out of bounds access, this loop should be capped at "< nb_cpus" instead of "<= nb_cpus". The freq_tables[] array is allocated in armada_8k_cpufreq_init(). Cc: stable@vger.kernel.org Fixes: f525a670533d ("cpufreq: ap806: add cpufreq driver for Armada 8K") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-06-24rust: macros: remove `module!`'s deprecated `author` keyGuilherme Giacomo Simoes
Commit 38559da6afb2 ("rust: module: introduce `authors` key") introduced a new `authors` key to support multiple module authors, while keeping the old `author` key for backward compatibility. Now that most in-tree modules have migrated to `authors`, remove: 1. The deprecated `author` key support from the module macro 2. Legacy `author` entries from remaining modules Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Benno Lossin <lossin@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250609122200.179307-1-trintaeoitogc@gmail.com [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-06-23Merge 6.16-rc3 into driver-core-nextGreg Kroah-Hartman
We need the driver-core fixes that are in 6.16-rc3 into here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-23cpufreq: armada-8k: make both cpu masks staticArnd Bergmann
An earlier patch marked one of the two CPU masks as 'static' to reduce stack usage, but if CONFIG_NR_CPUS is large enough, the function still produces a warning for compile testing: drivers/cpufreq/armada-8k-cpufreq.c: In function 'armada_8k_cpufreq_init': drivers/cpufreq/armada-8k-cpufreq.c:203:1: error: the frame size of 1416 bytes is larger than 1408 bytes [-Werror=frame-larger-than=] Normally this should be done using alloc_cpumask_var(), but since the driver already has a static mask and the probe function is not called concurrently, use the same trick for both. Fixes: 1ffec650d07f ("cpufreq: armada-8k: Avoid excessive stack usage") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>