| Age | Commit message (Collapse) | Author |
|---|
|
cpufreq_stats_create_table() sets stats->last_index to -1 if policy->cur
is not in the frequency table. It then stays at -1, because
cpufreq_stats_record_transition() returns early on old_index == -1 before
it gets to update last_index.
Commit 46a310b80bc2 ("[CPUFREQ] Don't set stat->last_index to -1 if
the pol->cur has incorrect value.") added that check. However, since
commit 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to
cpufreq_stats_record_transition()"), the stats reset is deferred to the
beginning of cpufreq_stats_record_transition(), before that check, and
cpufreq_stats_reset_table() ends with an unconditional
cpufreq_stats_update(). So if the "reset" attribute is written while
last_index is -1, the next frequency transition accesses
time_in_state[-1].
Fix it by also returning early on last_index == -1 in
cpufreq_stats_reset_table().
Fixes: 40c3bd4cfa6f ("cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()")
Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Link: https://patch.msgid.link/20261027133332.377546-1-zhongqiu.han@oss.qualcomm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
intel_pstate_driver_cleanup() frees per-CPU data without cancelling the
pending HWP notify delayed work. If hwp_notify_work is still scheduled
or running when the struct is freed, the work function accesses freed
memory via container_of().
Call intel_pstate_disable_hwp_interrupt() before kfree() to disable
the interrupt source and cancel the pending work, matching the pattern
used in intel_pstate_suspend() and intel_pstate_hwp_offline().
Fixes: d845cd901b28 ("cpufreq: intel_pstate: Support highest performance change interrupt")
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
[ rjw: Fixed the Fixes: tag ]
Link: https://patch.msgid.link/20261019222635.1741146-1-tristmd@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Merge cpufreq updates for 7.4:
- Minor fixes in various cpufreq drivers (Alexander Koskovich, Daniel
Schwierzeck, Frank Zhang, Haotian Zhang, Kathiravan Thirumoorthy,
Sumeet Pawnikar, and Xueqin Luo)
- Fix wrong behaviors on multi-node servers in the Loongson cpufreq
driver (Huacai Chen)
- Reject NULL from cpufreq_cpu_get() in the Rust code (Mehmet Koseoglu)
- Add suspend OPP to mediatek cpufreq driver and DT (Ryan Brue)
- Fixups for a few bugs identified by Sashiko in the amd-pstate cpufreq
driver (Mario Limoncielloi, Wentao Guan)
- Initial support for maximum frequency capacity handling on Zen6
client in amd-pstate (Mario Limonciello)
- Fix for amd-pstate-ut with 'Requested CPU Min frequency' BIOS option
(K Prateek Nayak)
- New Zen6 tuning values for EPP in amd-pstate (Mario Limonciello,
Vishal Badole)
- amd-pstate documentation fix (Karl Mehltretter)
- Restrict deferred downscaling to low load for shared policies in the
conservative cpufreq governor to avoid undesirable CPU frequency
reduction in some cases (Shengming Hu)
- Serialize sugov_start() against rate limit updates in the schedutil
cpufreq governor to avoid using a stale rate limit value (Hui Su)
* pm-cpufreq: (34 commits)
cpufreq: loongson3: Replace IOCSR read/write with MMIO ones
cpufreq: loongson3: Use global physical CPU ID in get/target callbacks
cpufreq: loongson3: Replace per-package mutex with per-node
cpufreq: loongson3: Adjust the width of id and val in smc_message
cpufreq: loongson3: Make this driver depend on MACH_LOONGSON64
cpufreq: schedutil: Serialize sugov_start() against rate limit updates
arm64: dts: mediatek: mt8173: Mark the lowest CPU OPPs for suspend
cpufreq: mediatek: Enter system sleep at the suspend OPP
cpufreq: qcom-cpufreq-hw: fix device node refcount leak in phandle parsing
cpufreq: qcom-nvmem: Add IPQ9650 support
cpufreq: Add Milos to cpufreq-dt-platdev blocklist
cpufreq: Use %pe to print error pointers symbolically
rust: rcpufreq_dt: add module alias
cpufreq: sti: avoid NULL dereference in dev_err()
cpufreq: tegra194: fix double-pointer error in get_cpu_ndiv
cpufreq: sparc-us2e: fix frequency table index copy-paste error
rust: cpufreq: reject NULL from cpufreq_cpu_get()
cpufreq: amd-pstate-ut: Fix max_freq and EPP test failures on Zen6
cpufreq: amd-pstate: Propagate cppc_set_auto_sel() errors on mode change
cpufreq: amd-pstate: Restore previous mode when changing driver mode fails
...
|
|
Merge ACPI CPPC library updates the CPPC cpufreq driver updates based on
them for 7.4:
- Fix multiple issues related to input validation, synchronization,
access safety, memory layout and register field validation, and error
handling in the ACPI CPPC library (Christian Loehle and Sumit Gupta)
- Select the frequency-invariance callback per CPU in the CPPC cpufreq
driver and create the FIE worker before enabling PCC callbacks in it
to avoid queueing work through a missing worker and dereferencing a
NULL pointer (Christian Loehle)
- Update the CPPC cpufreq driver entry in MAINTAINERS and add a new
entry for the ACPI CPPC library (Christian Loehle)
* acpi-cppc: (22 commits)
MAINTAINERS: ACPI: Add a separate CPPC entry
MAINTAINERS: cpufreq: Replace CPPC reviewer
cpufreq: CPPC: Create the FIE worker before enabling PCC callbacks
cpufreq: CPPC: Select the frequency-invariance callback per CPU
ACPI: CPPC: Accept requests to retain immutable autonomous selection
ACPI: CPPC: Propagate errors from cross-CPU FFH calls
ACPI: CPPC: Validate FFH register fields before hardware access
ACPI: CPPC: Keep Performance Limited clearable on NVIDIA T41
ACPI: CPPC: Clear Performance Limited without a stale read
ACPI: CPPC: Validate SystemIO overlaps across processors
ACPI: CPPC: Validate PCC overlaps across processors
ACPI: CPPC: Validate SystemIO register layouts
ACPI: CPPC: Validate and access PCC register layouts
ACPI: CPPC: Reject direct reads of write-only controls
ACPI: CPPC: Reject unsafe cross-CPU SystemMemory RMW
ACPI: CPPC: Release PCC data after probe failures
ACPI: CPPC: Release CPC descriptors through kobject
ACPI: CPPC: Serialize PCC EPP payload updates
ACPI: CPPC: Serialize PCC single-register payload updates
ACPI: CPPC: Propagate performance-control write errors
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
Pull CPUFreq Arm updates for 7.4 from Viresh Kumar:
"- Minor fixes to in various cpufreq drivers (Alexander Koskovich, Daniel
Schwierzeck, Frank Zhang, Haotian Zhang, Kathiravan Thirumoorthy,
Sumeet Pawnikar, and Xueqin Luo).
- Fix wrong behaviors on multi-node servers in Loongson driver (Huacai Chen).
- Reject NULL from cpufreq_cpu_get() in the Rust code (Mehmet Koseoglu).
- Add suspend OPP to mediatek driver and DT (Ryan Brue)."
* tag 'cpufreq-arm-updates-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
cpufreq: loongson3: Replace IOCSR read/write with MMIO ones
cpufreq: loongson3: Use global physical CPU ID in get/target callbacks
cpufreq: loongson3: Replace per-package mutex with per-node
cpufreq: loongson3: Adjust the width of id and val in smc_message
cpufreq: loongson3: Make this driver depend on MACH_LOONGSON64
arm64: dts: mediatek: mt8173: Mark the lowest CPU OPPs for suspend
cpufreq: mediatek: Enter system sleep at the suspend OPP
cpufreq: qcom-cpufreq-hw: fix device node refcount leak in phandle parsing
cpufreq: qcom-nvmem: Add IPQ9650 support
cpufreq: Add Milos to cpufreq-dt-platdev blocklist
cpufreq: Use %pe to print error pointers symbolically
rust: rcpufreq_dt: add module alias
cpufreq: sti: avoid NULL dereference in dev_err()
cpufreq: tegra194: fix double-pointer error in get_cpu_ndiv
cpufreq: sparc-us2e: fix frequency table index copy-paste error
rust: cpufreq: reject NULL from cpufreq_cpu_get()
cpufreq: airoha: fix probe failure with correct error check
|
|
Our server productions (e.g. Loongson-3D6000/3E6000) can have multiple
nodes in one package and SMC mailboxes are also per-node. However, IOCSR
read/write can only perform on the current node, while sometimes we want
to perform on other nodes (e.g. when switch governor, the get and target
callbacks are not run on target core). So replace IOCSR read/write with
MMIO ones.
Cc: stable@vger.kernel.org
Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support")
Tested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
Our server productions (e.g. Loongson-3D6000/3E6000) can have discrete
global physical CPU IDs while the core ID inside the packages are always
continuous. In these cases we should use global physical CPU IDs to get
and set frequencies.
Cc: stable@vger.kernel.org
Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support")
Signed-off-by: Hongliang Wang <wanghongliang@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
Our server productions (e.g. Loongson-3D6000/3E6000) can have multiple
nodes in one package and SMC mailboxes are also per-node. So replace the
per-package mutex with per-node one.
Cc: stable@vger.kernel.org
Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support")
Signed-off-by: Hongliang Wang <wanghongliang@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
The id field of smc_message is usually stand for the CPU ID. In the past
this driver was only tested for desktop and laptop productions so 4-bits
are enough. But now we have servers that can have as many as 256 cores,
so we need 8-bits CPU ID.
On the other hand, the val field is usually stand for CPU frequency so
12-bits are enough to represent 4GHz, and for higher frequencies there
is an extra bit to extend (enough for 8GHz).
In theory, this is a incompatible change, but fortunately the old SMC
firmwares are not widely shipped and can be updated on the air, thus we
can safely adjust the widths.
Cc: stable@vger.kernel.org
Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support")
Signed-off-by: Hongliang Wang <wanghongliang@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
32BIT Loongson machines don't have SMC and FreqCtrl registers, so make
this driver depend on MACH_LOONGSON64 (only for LoongArch based 64bit
machines currently).
Cc: stable@vger.kernel.org
Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support")
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux
Pull amd-pstate content for 7.4 (10/4/26) from Mario Limonciello:
"* Fixups for a few bugs identified by Sashiko
* Initial support for maximum frequency capacity handling on Zen6 / client
* Updated EPP tunings for Zen6 / client"
|
|
cpufreq_suspend() stops the governors at the start of system suspend, and
this driver has no .suspend callback, so each cluster sleeps at whatever
OPP it was last left at. On an MT8173 tablet (Amazon Fire HD 10, 2017),
entering suspend-to-RAM with both clusters at their highest OPP measured
63.5 mA. With this change and the lowest OPP marked, the same entry
measured 52.0 mA.
Use the generic suspend-frequency support, as cpufreq-dt does. Tables
without an opp-suspend entry leave suspend_freq at 0, which makes
cpufreq_generic_suspend() a no-op, so they are unaffected.
Assisted-by: LLM
Signed-off-by: Ryan Brue <ryanbrue.dev@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
of_parse_phandle_with_args() transfers a reference to the provider node
in out_args->np, which the caller is responsible for releasing with
of_node_put(). Neither qcom_get_related_cpus() nor
qcom_cpufreq_hw_cpu_init() ever puts args.np: they only put cpu_np, which
is a different node obtained from of_cpu_device_node_get(). The
reference is therefore leaked on every successful call, and
qcom_get_related_cpus() leaks one per present CPU.
Release args.np after the parsed index has been read in both call sites.
Fixes: 2849dd8bc72b ("cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver")
Assisted-by: DeepSeek-V4.1-Flash
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
Add IPQ9650 support to the Qualcomm NVMEM cpufreq driver so the supported
OPP can be selected at runtime using the eFuse value and the
opp-supported-hw OPP property. Also block the generic cpufreq-dt platform
device for IPQ9650 so the NVMEM-based driver is used.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
The Qualcomm Milos platform uses the qcom-cpufreq-hw driver so add it
to the cpufreq-dt-platdev driver's blocklist.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
Replace PTR_ERR() and %ld with %pe and pass the original pointer directly
to pr_err() and pr_warn(). The %pe format specifier prints a symbolic error
name (e.g. -ENOMEM) when CONFIG_SYMBOLIC_ERRNAME is enabled, otherwise it
falls back gracefully and prints the raw integer value. This makes messages
more readable without any functional change.
Signed-off-by: Sumeet Pawnikar <sumeet4linux@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
Add the missing `platform:cpufreq-dt` module alias so that the driver
can be automatically loaded when the platform device is registered.
Fixes: 06149d8f2216 ("cpufreq: Add Rust-based cpufreq-dt driver")
Cc: stable@vger.kernel.org
Signed-off-by: Frank Zhang <rmxpzlb@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
ddata.cpu is NULL-checked, then immediately passed to dev_err().
Replace with pr_err() to avoid dereferencing NULL.
Fixes: ab0ea257fc58 ("cpufreq: st: Provide runtime initialised driver for ST's platforms")
Signed-off-by: Xueqin Luo <luoxueqin@kylinos.cn>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
ndiv is already a u64 pointer, passing &ndiv to smp_call_function_single()
results in a u64** being written to instead of the caller's u64 variable,
so the caller always reads back an uninitialized ndiv. Drop the spurious
'&'.
Fixes: 0839ed1fd7ac ("cpufreq: tegra194: add soc data to support multiple soc")
Signed-off-by: Xueqin Luo <luoxueqin@kylinos.cn>
Reviewed-by: Sumit Gupta <sumitg@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
In us2e_freq_cpu_init(), the last two frequency writes both use
index [2] instead of [3] and [4] respectively, and the terminator
uses [3] instead of [5]. This is a copy-paste error where the index
was not incremented, causing the divider-6 and divider-8 entries to
overwrite the already-written divider-4 entry.
As a result, only three frequency steps (div 1, 2, and 4) are actually
available to the cpufreq core, while the intended dividers 6 and 8 are
silently lost. The struct us2e_freq_percpu_info::table[6] has room for
5 entries plus a terminator, matching the 5 hardware dividers.
Fix the indices so all five frequency steps are correctly populated:
table[0]=div1, table[1]=div2, table[2]=div4, table[3]=div6,
table[4]=div8, table[5]=TABLE_END.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Xueqin Luo <luoxueqin@kylinos.cn>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
|
|
Zen6 platforms expose conditions that cause two amd-pstate unit tests to
fail: low-power cores can report max_freq below the shared nominal_freq,
and multiple EPP preferences can alias to the same raw value.
Relax the max_freq >= nominal_freq assertion to max_freq >=
lowest_nonlinear_freq, and tolerate aliased EPP preferences by validating
the raw programmed value instead of string comparison.
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
|
|
amd_pstate_change_mode_without_dvr_change() iterates over the online CPUs
and calls cppc_set_auto_sel() to enable or disable hardware autonomous
selection, but discards its return value and unconditionally returns 0.
If the firmware rejects the request, the failure is hidden: the cpufreq
core records the mode transition as successful while the hardware stays in
its previous autonomous-selection state. The software mode and the actual
hardware behaviour then disagree, breaking the expected frequency scaling.
Check the return value of cppc_set_auto_sel() and propagate the first
error to the caller so the sysfs write reports the failure.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/bug/linux-d114a94a-655b-43a6-91b1-9484889726c9
Fixes: 3ca7bc818d8c ("cpufreq: amd-pstate: Add guided mode control support via sysfs")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20260921190235.3651688-2-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
amd_pstate_change_driver_mode() unregisters the currently active driver
before registering the requested mode. If amd_pstate_register_driver()
fails for the new mode, the function returns the error without restoring
anything, leaving the system with no cpufreq scaling driver at all until
a valid mode is manually re-selected.
Remember the mode that was active before the transition and, if
registering the requested mode fails, register the previous mode again so
the system keeps a working scaling driver. The original error is still
returned to the caller so the sysfs write reports the failure.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/bug/linux-5b138ddb-c88b-4f82-8a2d-f39446b625d4
Fixes: 3ca7bc818d8c ("cpufreq: amd-pstate: Add guided mode control support via sysfs")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20260921190235.3651688-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
If the highest frequency is known for a CPU, use this instead of
trying to calculate by linear interpolation.
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20261001142341.2934582-4-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
Update get_max_boost_ratio() to use the new amd_get_boost_ratio()
helper function instead of calling amd_get_effective_highest_perf()
directly.
This ensures the boost ratio is calculated correctly on systems where
frequency values should be used instead of performance values.
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20261001142341.2934582-3-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
Rename amd_get_boost_ratio_numerator() to amd_get_effective_highest_perf()
to better reflect that it returns the effective highest performance value
for a CPU, accounting for preferred cores and heterogeneous topologies.
Add a new helper amd_get_boost_ratio() for doing both for boost
ratio calculations and update callers to use it.
This refactoring is needed because on some AMD systems (Zen6+),
the boost ratio should be calculated from frequency values rather than
performance values.
Newer versions of the ACPI will introduce a proper interface
for getting this information, but for now hardcode values so that
these systems perform as intended and to unblock future scheduler
work while we continue to wait.
For now use some temporary hardcoded values for Zen6 platforms.
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20261001142341.2934582-2-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
The per-CPU-type EPP values for the Zen6 client platform are further
tuned based on platform characterization. Adjust the performance and
low-power core entries so each core type uses its intended EPP settings.
Reviewed-by: Mario Limonciello <Mario.Limonciello@amd.com>
Signed-off-by: Vishal Badole <Vishal.Badole@amd.com>
Link: https://lore.kernel.org/r/20260928203523.1290623-1-Vishal.Badole@amd.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
amd_pstate_update_status() evaluates mode_state_machine[cppc_state]
[mode_idx] before taking amd_pstate_driver_lock, and then re-evaluates it
again once the lock is held. cppc_state is global and only stable under
the lock, so concurrent sysfs writes race:
CPU 0 CPU 1
----- -----
// cppc_state == A, mode == B
if (mode_state_machine[A][B]) // sees non-NULL
if (mode_state_machine[A][B])
guard(&amd_pstate_driver_lock);
mode_state_machine[A][B](B);
cppc_state = B;
guard(&amd_pstate_driver_lock);
// cppc_state is now B
mode_state_machine[B][B](B); // NULL -> NULL deref
The re-read under the lock can resolve to a self-transition (NULL
pointer, immediate NULL deref) or to an unexpected transition that
redundantly runs amd_pstate_driver_cleanup(), double-freeing
current_pstate_driver->attr.
Take the lock first, then read cppc_state and resolve the transition
function exactly once into a local before calling it, so the check and
the call observe the same state.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/bug/linux-f86ff3a6-55df-4eef-8e4d-62ac270dba25
Fixes: 6f0b13f16f7a ("cpufreq/amd-pstate: Overhaul locking")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20260922022347.1270746-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
After commit d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall
back to cpuinfo.max_freq"), cpufreq pressure appears in the CPU load
balancer unexpectedly in some cases in which it was not present before,
leading to confusion and uncertainty.
Clearly, the scheduler assumes that cpufreq pressure will not be set
unless the capacity reference frequency of the CPU is known, and the
commit mentioned above violates that assumption.
However, in some cases the capacity reference frequency of the CPU is
in fact known even though arch_scale_freq_ref() returns 0 and in those
cases it should be possible to set cpufreq pressure as appropriate.
For this purpose, introduce a new cpufreq driver callback returning
the CPU capacity reference frequency, .scale_freq_ref(), and make
cpufreq_update_pressure() invoke it, if present, instead of falling
back to cpuinfo.max_freq unconditionally.
Add that callback to the intel_pstate driver and make it return 0 unless
the scale-invariant capacity of the given CPU has been explicitly set,
in which cases its reference frequency is always cpuinfo.max_freq.
Fixes: d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq")
Reported-by: Jianyong Wu <wujianyong@hygon.cn>
Closes: https://lore.kernel.org/linux-pm/20260915065747.1671965-1-wujianyong@hygon.cn/
Tested-by: Jianyong Wu <wujianyong@hygon.cn>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> # Intel hybrid parts
Tested-by: Chen Yu <yu.c.chen@intel.com>
[ rjw: Add READ_ONCE() around a capacity_perf read ]
Link: https://patch.msgid.link/12975163.O9o76ZdvQC@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since commit 9dfd13f80c85 ("cpufreq/amd-pstate: Toggle auto_sel in active
mode on shared memory systems"), shmem_init_perf() programs
AUTONOMOUS_SELECTION_ENABLE unconditionally, including in active mode.
Platforms that exclusively support autonomous selection report this field
as an Integer of 1, as required by the ACPI specification, instead of as a
register descriptor. cppc_get_reg_val() reads such a field back
successfully, but cppc_set_reg_val() rejects the write with -EOPNOTSUPP
because the entry is not an ACPI_TYPE_BUFFER.
shmem_init_perf() propagates that error, so every amd_pstate_epp_cpu_init()
fails, cpufreq_register_driver() ends up with an empty policy list and
returns -ENODEV, and amd-pstate refuses to load at all:
amd_pstate: failed to set auto_sel, ret: -95
amd_pstate: Failed to initialize CPU 0: -95
...
amd_pstate: failed to register with return -19
Skip the write when the register already holds the value the requested mode
needs. Active and guided mode are fixed on these platforms, which report
auto_sel as 1, while passive mode still fails to load on a platform that
cannot disable autonomous selection, exactly as it did before the
offending commit.
Fixes: 9dfd13f80c85 ("cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory systems")
Cc: stable@vger.kernel.org
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: LFRon <ronforever@outlook.com>
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Link: https://lore.kernel.org/r/20260918090909.86544-1-guanwentao@uniontech.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
amd_pstate_set_dynamic_epp() first applies the EPP value derived from
the current platform profile via amd_pstate_set_epp() and only then
allocates the profile name and registers the platform profile handler
and the power supply notifier. All failures after the EPP has been
programmed jump to the cleanup label, which restores the previously
programmed EPP value.
However, if the kasprintf() of the profile name fails, the function
returns -ENOMEM directly, bypassing the cleanup label, so the EPP value
programmed above is never rolled back even though enabling dynamic EPP
has failed.
Make the allocation failure path jump to the cleanup label as well, so
that the previous EPP value is restored consistently on all error
paths.
Fixes: b7294b627598 ("cpufreq/amd-pstate: Add dynamic EPP as an "energy_performance_preference" mode")
Signed-off-by: Xueqin Luo <luoxueqin@kylinos.cn>
Link: https://lore.kernel.org/r/20260825131400.1509428-1-luoxueqin@kylinos.cn
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
cppc_freq_invariance_init() creates the PCC worker only if an online CPU
currently has PCC counters. A shared policy can also initialize an offline
PCC member. When that CPU comes online, its callback queues work through
the missing kworker_fie and dereferences NULL. A later hot-added PCC policy
can encounter the same missing worker.
Create the worker when policy initialization encounters PCC counters,
before initializing their work and publishing any callbacks. Serialize
creation and reuse the worker until driver teardown. This covers offline
policy members and later PCC policies without creating an unused deadline
worker on direct-counter-only systems.
If worker allocation or scheduling setup fails, leave FIE unregistered for
that policy. Keep the global FIE setting unchanged so direct-counter
policies remain independent of worker setup and existing policies still
drain their initialized work during teardown. Publish kworker_fie only
after successful setup, allowing a later policy initialization to retry.
Fixes: 997c021abc6e ("cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regs")
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Sumit Gupta <sumitg@nvidia.com>
Link: https://patch.msgid.link/20260916162805.1039247-21-christian.loehle@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
cppc_cpufreq_cpu_fie_init() initializes deferred work only for CPUs whose
feedback counters use PCC. However, if any CPU in a shared policy uses PCC,
it installs the PCC tick callback for the entire policy. With FIE enabled,
a non-PCC CPU then queues an uninitialized irq_work and can call a NULL
function pointer when that work runs.
Choose the frequency-invariance callback separately for each CPU using
the recorded work-initialization state. Processor removal can unpublish
the CPC descriptor before callback registration, so querying its counter
transport again can incorrectly select direct reads for a PCC CPU.
Register the callbacks after all counter initialization has completed, so
a failed initial read for an online CPU cannot leave a partially
registered policy. PCC CPUs use their initialized deferred work, while
non-PCC CPUs read their own counters directly from the tick.
Fixes: 997c021abc6e ("cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regs")
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Sumit Gupta <sumitg@nvidia.com>
Link: https://patch.msgid.link/20260916162805.1039247-20-christian.loehle@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ACPI permits Autonomous Selection Enable to be Integer 1 when the platform
always selects performance autonomously. cppc_get_auto_sel() returns that
value, but cppc_set_auto_sel() rejects the Integer even when asked to keep
autonomous selection enabled. AMD shared-memory initialization consequently
fails in active or guided mode after successfully reading the capability.
Accept a request to keep this immutable field enabled without issuing a
register access. Expose the immutable encoding to callers, separately from
the current value of a writable register.
Before an AMD shared-memory transition to passive mode, reject immutable
autonomous selection on any present CPU. Otherwise a guided-to-passive
transition ignores the failed disable and reports the wrong mode, while
active-to-passive unregisters the working driver before passive policy
initialization fails. Check under the driver mode lock before invoking
either transition, including known offline CPUs.
Serialize this capability query with descriptor publication and removal.
ACPI processor removal drops the descriptor before taking the CPU hotplug
write lock, so the caller's cpus_read_lock() alone cannot protect the
lookup. Unpublish under the same mutex before releasing a descriptor,
including when adding its kobject fails.
The cppc-cpufreq auto_select attribute can also request one while
autonomous selection is already enabled. If the subsequent bounds update
fails, its rollback requests zero and clears the cached mode regardless
of the previous state. For an immutable field the disable request fails,
leaving the cached mode wrong. Save and restore the previous mode instead.
This also avoids disabling an already-enabled writable control on that
error path.
Fixes: c984f5d5d45b ("ACPI: CPPC: Add auto select register read/write support")
Fixes: ea3db45ae476 ("cpufreq: cppc: Update MIN_PERF/MAX_PERF in target callbacks")
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Sumit Gupta <sumitg@nvidia.com>
Link: https://patch.msgid.link/20260916162805.1039247-19-christian.loehle@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The CPC descriptor embeds the kobject used for its sysfs directory, but
it has no release callback and processor exit frees the descriptor
immediately after kobject_put(). It also unmaps register resources and
releases PCC state before sysfs removal has drained active attribute
callbacks.
Provide a release callback which unmaps and frees the descriptor, and use
the same cleanup helper before kobject initialization. Once initialized,
let kobject_put() own descriptor cleanup so its error path cannot free the
object twice.
On processor exit, first unpublish the per-CPU descriptor and remove its
sysfs directory, then release PCC state and drop the kobject reference.
This keeps all resources valid while sysfs callbacks are active and also
works with delayed kobject release.
The frequency-invariance teardown can run after processor removal has
unpublished a descriptor. Remember which PCC work items were initialized
so policy exit drains them without looking up that descriptor. Also make
the counter-transport query tolerate a missing descriptor.
Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260724134251.1632824-1-christian.loehle%40arm.com
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Sumit Gupta <sumitg@nvidia.com>
Link: https://patch.msgid.link/20260916162805.1039247-7-christian.loehle@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Writable _CPC controls are Register descriptors encoded as Buffer objects.
Integer entries represent fixed values or legacy placeholders for
unsupported optional registers; Autonomous Selection Integer 1 is the
special immutable form which enables operation without Desired Performance.
The parser accepts arbitrary object types and cpc_write() assumes that its
argument contains a GAS. Malformed firmware can therefore make it interpret
an Integer union member as a register.
Validate the portion of each encoding consumed by the driver: bound Integer
capabilities stored in u32 fields to U32_MAX, and require Buffer entries to
start with a complete Generic Register descriptor with the expected header.
Do not restrict an Integer Counter Wraparound Time. Both AML Integers and
the kernel interface are 64-bit, despite the DWORD annotation in the ACPI
table. Continue tolerating Integer 0 placeholders for absent optional
Buffer registers to avoid breaking legacy platforms. Report their invalid
encoding as a firmware bug. Retain type checks in cpc_write() as defense in
depth. Reject an attempt to disable immutable Autonomous Selection instead
of silently applying only the EPP part of the request.
Capability registers are read into u64 temporaries but exposed through u32
fields. Reject values above U32_MAX instead of allowing them to be
truncated. In particular, a truncated Highest Performance value can become
a zero divisor in the performance-to-frequency conversion. Enforce the
required ordering from Highest through Nominal, Lowest Nonlinear, and
Lowest Performance, and constrain a present Guaranteed Performance to the
inclusive Lowest-to-Nominal range. Also reject reversed frequency anchors
and unequal frequency anchors with identical performance anchors. Those
invalid tuples otherwise make affine-conversion differences wrap or divide
by zero.
Check mandatory object presence separately from the Integer-zero convention
for absent optional fields.
Reject Minimum and Maximum Performance readbacks above U32_MAX before
narrowing them. A truncated minimum could otherwise become an explicit
zero update when cppc-cpufreq writes the initial controls back to the
platform.
Minimum Performance also defines zero as a real no-limit value, but the
exported cppc_set_perf() interface historically used zero to omit a bound.
Add a minimum-valid flag so callers can request zero without changing that
legacy convention. Set it when reading a supported Minimum Performance
register, preserving zero across cppc-cpufreq initialization and exit.
Keep zero-as-omit for Maximum Performance, whose no-limit encoding is all
ones, not zero. Initialize amd-pstate's control structure with the new flag
clear: its shared-memory backend does not record bios_min_perf, so its
zero-valued restore requests must remain omitted.
Performance Limited is listed as a required Buffer, but the interface does
not depend on it to control performance and the specification permits a
platform with no limiting indication to always report zero. Preserve
compatibility with firmware that represents that case using a NULL register
descriptor instead of disabling CPPC entirely.
Emit an error when a present _CPC package fails parsing or initialization
so such firmware and resource failures no longer silently suppress cpufreq.
Initialize malformed-package failures to -EINVAL and preserve specific
allocation, mapping, and unsupported-access errors in that diagnostic.
Fixes: 337aadff8e45 ("ACPI: Introduce CPU performance controls using CPPC")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260724134251.1632824-1-christian.loehle%40arm.com
Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Sumit Gupta <sumitg@nvidia.com>
Link: https://patch.msgid.link/20260916162805.1039247-3-christian.loehle@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
For a shared cpufreq policy, dbs_update() derives the load used for the
frequency decision from the maximum load among its CPUs, but it may
also record deferred idle periods accumulated by an idle CPU in the
policy.
Consequently, a single update can contain both a high decision load
from one CPU and multiple deferred idle periods from another CPU. The
conservative governor applies the deferred down steps before evaluating
the decision load. If that load subsequently triggers an up step, the
deferred down steps can outweigh the single up step and produce a net
frequency reduction.
This was observed on a policy shared by CPUs 2 and 3. A CPU-bound
SCHED_EXT task kept CPU 2 fully utilized while CPU 3 remained idle.
On this system, SCHED_EXT generated update-util callbacks less
frequently than CFS, resulting in sparse DBS updates such as:
load=100 idle_periods=7 interval=59 ms
load=100 idle_periods=4 interval=39 ms
load=100 idle_periods=2 interval=19 ms
load=100 idle_periods=7 interval=59 ms
With the default 5% frequency step and a 2.6 GHz policy maximum, seven
deferred periods reduce the requested frequency by seven 130 MHz steps
before the high decision load adds only one step. Repeated updates
therefore keep the policy near 530 MHz even though CPU 2 is fully
utilized.
There are two load values relevant to this behavior:
* sample_load is calculated from the busy and elapsed time of the
current sample.
* decision_load is returned by dbs_update() for the governor's
frequency decision. After a long idle interval, it may reuse
prev_load to improve the response to a waking task and can therefore
differ from sample_load.
The problem is that idle_periods is derived from accumulated idle time
and is applied independently of whether the current sample load is in
the conservative governor's downscaling region. A high sample load and
multiple deferred idle periods can therefore coexist, particularly
when updates are sparse.
As suggested by Zhongqiu Han, calculate the sample load separately from
the decision load. If no time has elapsed, use prev_load for the sample
load as the existing load calculation does, since no load can be
calculated for that interval.
Record the maximum sample load for the policy and apply deferred down
steps only when it is below down_threshold. This makes deferred
downscaling follow the same threshold that the conservative governor
normally uses to determine whether the policy load is low enough to
reduce the frequency.
The existing code applies deferred down steps whenever idle_periods is
valid, regardless of the sample load. When the decision load is in the
hold region, the locally adjusted frequency is not submitted unless
another frequency-update branch is taken. Thus, when the sample and
decision loads are the same and both are in the hold region, this
change does not alter the requested frequency.
The difference becomes visible when the decision load causes a
frequency update. In particular, if it exceeds up_threshold, the
governor applies a single up step after the deferred down steps and
submits the resulting request. Multiple deferred down steps can then
outweigh that up step and cause a frequency reduction even when the
sample load is above down_threshold.
With this change, deferred down steps are skipped whenever the maximum
sample load is at or above down_threshold, keeping deferred downscaling
consistent with the conservative governor's threshold semantics. The
requested frequency may therefore be higher than with the existing
behavior when deferred idle periods are present and the decision load
causes a frequency update. This is intentional, because the lower
request previously resulted from applying deferred downscaling while
the sampled policy load was outside the governor's downscaling region.
Accelerated deferred downscaling remains available when the policy
sample load is below down_threshold, including after a workload has
completed and the policy has become idle.
Fixes: 00bfe05889e9 ("cpufreq: conservative: Decrease frequency faster for deferred updates")
Cc: All applicable <stable@vger.kernel.org>
Reviewed-by: Luo Haiyang <luo.haiyang@zte.com.cn>
Reviewed-by: Run Zhang <zhang.run@zte.com.cn>
Suggested-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn>
Link: https://patch.msgid.link/20260916140926740-DCokXh6dAgtqDn1EWdCh@zte.com.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux
Pull amd-pstate 7.4 content (2026-09-14) from Mario Limonciello:
"* Fix for amd-pstate-ut with 'Requested CPU Min frequency' BIOS option
* New Zen6 tuning values for EPP
* Documentation fix"
* tag 'amd-pstate-v7.4-2026-09-14' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux:
cpufreq/amd-pstate: Remove obsolete amd_dynamic_epp documentation
cpufreq/amd-pstate: Show a warning if missing EPP tunings
cpufreq/amd-pstate: Add EPP tunings for Zen6 client platforms
cpufreq/amd-pstate: Add per SoC and per core type EPP tuning values
cpufreq/amd-pstate-ut: Fix amd_pstate_ut_check_freq failure with 'Requested CPU Min frequency' BIOS option
|
|
EPP tunings are going to be more important going forward. Show a warning
if on a heterogenous platform without them.
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Suggested-by: Christian Ludloff <ludloff@gmail.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
|
|
Zen6 client platforms perform better with individual tunings for
different core types. Add initial EPP tuning values for those
platforms.
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
|
|
On newer SoCs the behavior of the platform has changed, and using
the same EPP values for everything will yield worse results than expected.
Add a x86_cpu_id match table that allows setting policies on a
per-SoC/per-core type basis. If a SoC is missing, fallback to legacy
values that are used.
Changes also:
- Change epp_values array and amd_pstate_cpu_epp_values() from unsigned int to u8
- Add static_assert to ensure epp_values has rows for all CPU types
- Fix show_energy_performance_preference() loop to exclude uninitialized
EPP_INDEX_CUSTOM and EPP_INDEX_DYNAMIC slots
- Add debug print statements
- Remove amd_pstate_get_epp_from_platform_profile and inline the logic
- Fix cleanup path in amd_pstate_set_dynamic_epp
- Change show_energy_performance_preference to use for loop with preference tracking
- Add debug prints in amd_pstate_init_epp_values
Behavioral change: show_energy_performance_preference() now returns a numeric
EPP value via sysfs when the cached EPP does not match any named preference,
instead of returning -EINVAL as before. This provides visibility into custom
EPP values set by hardware or BIOS.
No new platforms are added in this commit.
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
|
|
Merge cpufreq fixes for 7.3-rc3:
- Zero-initialize policy cpumask and initialize policy rwsem before
exposing the policy sysfs interface (Runyu Xiao and Zhongqiu Han)
* pm-cpufreq:
cpufreq: zero-initialize policy cpumask before sysfs publication
cpufreq: initialize policy rwsem before sysfs publication
|
|
CPU Min frequency' BIOS option
Since commit 608a76b65288 ("cpufreq/amd-pstate: Add support for the
"Requested CPU Min frequency" BIOS option"), amd-pstate driver sets
policy->min to frequency corresponding to bios_min_perf if a valid BIOS
programmed min frequency value is detected.
amd_pstate_ut_check_freq expects policy->min to always match
lowest_nonlinear_freq which does not hold true on platforms with user
configured BIOS min freq.
Update the test case to compare policy->min to bios_min_freq on
platforms that set it. Final comparison is adjusted to account for
insane values by clamping the result within the supported frequency
range.
While at it, move freq_to_perf() and perf_to_freq() helpers to internal
header to allow their use from amd-pstate-ut.
Reviewed-by: Mario Limonciello <superm1@kernel.org>
Fixes: 608a76b65288 ("cpufreq/amd-pstate: Add support for the "Requested CPU Min frequency" BIOS option")
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20260909102650.4582-1-kprateek.nayak@amd.com
Signed-off-by: Mario Limonciello <superm1@kernel.org>
|
|
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(),
i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus
masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate
kmalloc_node() allocation, so its bitmap holds whatever the slab allocator
left behind:
cpufreq_online()
cpufreq_policy_alloc()
alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */
kobject_init_and_add() /* policy%u/ appears in sysfs */
cpufreq_policy_online()
cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */
This leaves a window in which the sysfs attributes are already reachable
while policy->cpus is still garbage. show()/store() gate on
policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero
bitmap makes them run the attribute callbacks on a policy that is not
initialized yet.
Fix this by using zalloc_cpumask_var() for policy->cpus.
Fixes: 2fc3384dc75b ("cpufreq: Initialize policy->kobj while allocating policy")
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/20260901143635.4106960-1-zhongqiu.han@oss.qualcomm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
cpufreq_policy_alloc() initializes policy->rwsem after
kobject_init_and_add() has created the policy sysfs directory and its
default attributes. A sysfs access can therefore reach a policy callback
before the semaphore has been initialized.
Initialize policy->rwsem before publishing the policy kobject so sysfs
callbacks always see an initialized semaphore.
Fixes: 2fc3384dc75b ("cpufreq: Initialize policy->kobj while allocating policy")
Cc: All Applicable <stable@vger.kernel.org>
Link: https://lore.kernel.org/all/20260830155301.2713780-1-runyu.xiao@seu.edu.cn/
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/20260902041915.3453421-1-runyu.xiao@seu.edu.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
dev_pm_domain_attach_list() returns the number of attached PM domains
on success (a positive count), or a negative error code on failure.
The driver checks "if (ret)" which treats a successful attachment of
one or more PM domains as an error, causing the probe to fail with
return code 1.
Fix by checking "if (ret < 0)" like all other users of this API.
Cc: stable@vger.kernel.org
Fixes: 84cf9e541ccc ("cpufreq: airoha: Add EN7581 CPUFreq SMCCC driver")
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more power management updates from Rafael Wysocki:
"These fix two issues in the intel_rapl power capping driver, fix a
potential issue in the schedutil cpufreq governor on 32-bit systems,
fix a runtime PM issue related to failing system suspend, and update
the intel_pstate cpufreq driver:
- Fix a kernel panic during PMU unbind in the intel_rapl power
capping driver and sign-extend the PMU delta on counter wraparound
in it to avoid misreporting energy (Sumeet Pawnikar and Yifan Li)
- Unblock runtime PM when device prepare fails that was not done by
mistake (Shibo Zhu)
- Fix possible rate limit overflow on 32-bit systems in the schedutil
cpufreq governor (Hui Su)
- Consolidate HWP P-states initialization in the intel_pstate cpufreq
driver and make that driver avoid using the DESIRED_PERF HWP hint
when the Dynamic Efficiency Control (DEC) is enabled in the
processor to avoid inconsistent behavior (Rafael Wysocki)"
* tag 'pm-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
powercap: intel_rapl: Fix kernel panic during PMU unbind
PM: sleep: Unblock runtime PM when device prepare fails
powercap: intel_rapl: Sign-extend the PMU delta on counter wraparound
cpufreq: intel_pstate: Avoid using DESIRED_PERF when DEC is enabled
cpufreq: intel_pstate: Consolidate HWP P-states initialization
cpufreq: schedutil: Fix rate limit overflow
|
|
Merge additional cpufreq updates and one update related to system sleep
for 7.3-rc1:
- Unblock runtime PM when device prepare fails that was not done by
mistake (Shibo Zhu)
- Fix possible rate limit overflow on 32-bit systems in the schedutil
cpufreq governor (Hui Su)
- Consolidate HWP P-states initialization in the intel_pstate cpufreq
driver and make that driver avoid using the DESIRED_PERF HWP hint
when the Dynamic Efficiency Control (DEC) is enabled in the processor
to avoid inconsistent behavior (Rafael Wysocki)
* pm-cpufreq:
cpufreq: intel_pstate: Avoid using DESIRED_PERF when DEC is enabled
cpufreq: intel_pstate: Consolidate HWP P-states initialization
cpufreq: schedutil: Fix rate limit overflow
* pm-sleep:
PM: sleep: Unblock runtime PM when device prepare fails
|
