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
rapl_package_add_pmu() fails internally at perf_pmu_register(),
and rapl_pmu_update() leaves the global rapl_pmu.pmu structure
zero-initialized via memset and returns an error. But any
previously probed packages retain has_pmu = true.
When the driver is subsequently unbound or removed,
rapl_package_remove_pmu_locked() sees has_pmu == true and
unconditionally calls perf_pmu_unregister(&rapl_pmu.pmu) on the
zeroed-out structure. This attempts a list_del_rcu() on a NULL
list head, immediately causing a kernel panic.
Fix this by checking if the PMU is actually registered before
attempting to unregister it.
Signed-off-by: Sumeet Pawnikar <[email protected]>
Reviewed-by: Abel Vesa <[email protected]>
[ rjw: Added empty line after the new conditional ]
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
The RAPL PMU misreports energy when the hardware energy counter
overflows and wraps back to zero. perf event counts are defined to
increase monotonically, but a single wraparound makes the PMU event
count jump backwards by nearly the full counter range, and consumers
that take the difference of two reads in unsigned arithmetic then
underflow and report an absurd value.
On a Panther Lake system (energy unit 61.035 uJ, counter range
262144 J) the package counter wraps every ~2.9 hours at 25 W, and
turbostat prints one bogus sample per wraparound, per domain:
PkgTmp PkgWatt CorWatt GFXWatt RAMWatt SysWatt
44 24.97 16.30 3.90 1.87 2145386370.35
43 2145240612.10 16.13 4.02 1.91 40.46
The RAPL energy counters are 32-bit wide on every register interface:
MSR, MMIO and TPMI all describe ENERGY_COUNTER with a GENMASK(31, 0)
mask. rapl_read_data_raw() applies that mask, so event_read_counter()
returns the counter zero-extended in a u64.
rapl_event_update() then computes
delta = new_raw_count - prev_raw_count;
without reducing the result modulo 2^32. While the counter does not
wrap this is correct, but once the hardware counter wraps,
new_raw_count < prev_raw_count and delta becomes (true_delta - 2^32),
a large negative value. Declaring delta as s64 only makes that value
representable; it does not correct it. That bogus delta is scaled and
added to event->count, which is where the backwards jump comes from.
Fix it the way arch/x86/events/rapl.c has done since the RAPL PMU was
first introduced: shift both values up so that the 64-bit subtraction
reduces modulo 2^32, then shift the difference back down with an
arithmetic shift to sign-extend it.
This is correct as long as at most one wraparound happens between two
updates, which the existing overflow hrtimer already guarantees: its
period is half of the counter range at the 200 W reference used in
rapl_package_add_pmu_locked().
The problem has been present since the powercap RAPL PMU was added, but
only affected TPMI RAPL until commit 748d6ba43a ("powercap:
intel_rapl: Enable MSR-based RAPL PMU support") routed MSR RAPL through
the same PMU, which exposed it on client platforms such as Panther Lake.
Fixes: 575024a8aa ("powercap: intel_rapl: Introduce APIs for PMU support")
Reported-by: Jyoti, Anand B <[email protected]>
Signed-off-by: Li, Yifan <[email protected]>
Signed-off-by: Gao Jianfeng <[email protected]>
Tested-by: Jyoti, Anand B <[email protected]>
Acked-by: Srinivas Pandruvada <[email protected]>
Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Pull x86 MSR updates from Ingo Molnar:
- Streamline the x86 MSR handling APIs along the 64-bit variants,
simplifying the interfaces.
Removal of the old APIs is planned for the next cycle, to reduce
churn & integration pain (Juergen Gross)
* tag 'x86-msr-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (21 commits)
x86/mce: Work around build warning after MSR-interface switch
cpufreq: Stop using 32-bit MSR interfaces
x86/featctl: Stop using 32-bit MSR interfaces
KVM/x86: Stop using 32-bit MSR interfaces
x86/mtrr: Stop using 32-bit MSR interfaces
acpi: Stop using 32-bit MSR interfaces
powercap: Stop using 32-bit MSR interfaces
thermal/intel: Stop using 32-bit MSR interfaces
x86/olpc: Stop using 32-bit MSR interfaces
x86/hyperv: Stop using 32-bit MSR interfaces
hwmon: Stop using 32-bit MSR interfaces
EDAC: Stop using 32-bit MSR interfaces
x86/cpu: Stop using 32-bit MSR interfaces
x86/apic: Stop using 32-bit MSR interfaces
x86/resctrl: Stop using 32-bit MSR interfaces
x86/tsc: Stop using 32-bit MSR interfaces
x86/amd: Stop using 32-bit MSR interfaces
x86/pci: Stop using 32-bit MSR interfaces
x86/hygon: Stop using 32-bit MSR interfaces
x86/mce: Stop using 32-bit MSR interfaces
...
intel_rapl_tpmi_probe() invokes rapl_package_add_pmu() but ignores its
return value, so a PMU registration failure would leave the driver
reporting probe success despite the PMU being absent, with no log
trace.
Since PMU registration is an optional auxiliary feature for perf energy
counters, its failure should not break the primary powercap functionality.
Check the return value and log a warning to ensure graceful degradation.
Fixes: 963a9ad3c5 ("powercap: intel_rapl_tpmi: Enable PMU support")
Signed-off-by: Sumeet Pawnikar <[email protected]>
[ rjw: Changed the log level of the new message to "info" ]
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
cpumask_show() is a sysfs show callback, so use sysfs_emit() and
cpumask_pr_args() to emit the mask in it.
This prepares for removing cpumap_print_to_pagebuf().
Signed-off-by: Yury Norov <[email protected]>
[ rjw: Subject and changelog tweaks ]
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
When topology_physical_package_id()/topology_logical_die_id() returns
a negative value, rapl_add_package_cpuslocked() returns ERR_PTR(-EINVAL)
directly without freeing the rapl_package structure that was just
allocated by kzalloc_obj(), leaking memory on every failed package
addition.
Use the existing err_free_package label so that the allocation is
released on the error path.
Signed-off-by: Sumeet Pawnikar <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Currently, PL4 and MSR-based RAPL PMU support are detected using
separate CPU ID tables (pl4_support_ids and pmu_support_ids) in the
MSR driver probe path. This creates a maintenance burden since adding
a new CPU requires updates in two places: the rapl_ids table and one
or both of these capability tables.
Consolidate PL4 and PMU capability information directly into
struct rapl_defaults by adding msr_pl4_support and msr_pmu_support
flags. This allows per-CPU capability to be expressed in a single
place alongside other per-CPU defaults, eliminating the duplicate
CPU ID tables entirely.
No functional changes are intended.
Co-developed-by: Zhang Rui <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Acked-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Link: https://patch.msgid.link/20260331211950.3329932-8-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
MSR-specific RAPL primitives differ from those used by TPMI and MMIO
interfaces. Keeping them in the common driver requires
interface-specific handling logic and makes the common layer
unnecessarily complex.
Move the MSR primitive definitions and associated bitmasks into the
MSR interface driver. This change includes:
1. Move MSR-specific bitmask definitions to RAPL MSR driver.
2. Add MSR-local struct rapl_primitive_info instance and assign it to
priv->rpi during MSR probe.
3. Remove the primitive assignment logic from rapl_config() in the
common driver.
No functional changes are intended.
Co-developed-by: Zhang Rui <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Link: https://patch.msgid.link/20260331211950.3329932-7-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
MMIO-specific primitives differ from those used by the TPMI interface.
The MSR and MMIO interfaces shared the same primitives in the common
driver, but MMIO does not require many MSR-specific entries (like PSYS).
Keeping these in the common driver does not add any value and requires
interface-specific handling logic that makes the common layer
unnecessarily complex.
Move the MMIO primitive definitions and associated bitmasks into the
MMIO interface driver. This change includes:
1. Add MMIO-local struct rapl_primitive_info instance without
MSR-specific entries and assign it to priv->rpi during MMIO
initialization.
2. Remove the RAPL MMIO case from rapl_config() in the common driver.
No functional changes are intended.
Co-developed-by: Zhang Rui <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Link: https://patch.msgid.link/20260331211950.3329932-6-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
TPMI-specific RAPL primitives differ from those used by MSR and MMIO
interfaces. Keeping them in the common RAPL driver requires
interface-specific handling logic and makes the common layer
unnecessarily complex.
Move the TPMI primitive definitions and associated bitmasks into the
TPMI interface driver. This change includes:
1. Move TPMI-specific bitmask definitions from intel_rapl_common.c to
intel_rapl_tpmi.c.
2. Add TPMI-local struct rapl_primitive_info instance and assign it to
priv->rpi during TPMI probe.
3. Remove the RAPL TPMI related definitions from the common driver.
No functional changes are intended.
Co-developed-by: Zhang Rui <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Link: https://patch.msgid.link/20260331211950.3329932-5-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
RAPL primitive information varies across different RAPL interfaces
(MSR, TPMI, MMIO). Keeping them in the common code adds no benefit, but
requires interface-specific handling logic and makes the common layer
unnecessarily complex.
Move the primitive info infrastructure to the shared header to allow
interface drivers to configure RAPL primitives. Specific changes:
1. Move struct rapl_primitive_info, enum unit_type, and
PRIMITIVE_INFO_INIT macro to intel_rapl.h.
2. Change the @rpi field in struct rapl_if_priv from void * to
struct rapl_primitive_info * to improve type safety and eliminate
unnecessary casts.
No functional changes. This is a preparatory refactoring to allow
interface drivers to supply their own RAPL primitive settings.
Co-developed-by: Zhang Rui <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Link: https://patch.msgid.link/20260331211950.3329932-4-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
MSR-specific RAPL defaults differ from those used by the TPMI interface.
The MMIO and MSR interfaces shared the same rapl_defaults pointer in the
common driver, but MMIO does not require the CPU-specific variations
needed by MSR. Keeping these in the common driver adds unnecessary
complexity and MSR-specific initialization.
Move MSR defaults and CPU matching into the MSR interface driver.
Moves
-----
* Move rapl_check_unit_atom(), set_floor_freq_atom(), and
rapl_compute_time_window_atom() into intel_rapl_msr.c.
* Move MSR unit-field GENMASK definitions and local constants.
* Move all MSR-related rapl_defaults tables and the CPU-ID matching
logic (rapl_ids[]) into the MSR driver.
* Move iosf_mbi dependencies (floor-frequency control and related MBI
register definitions) as they are MSR-platform specific.
Modifications
-------------
* Replace the common driver's platform-device manual alloc/add sequence
with platform_device_register_data() in the MSR driver to pass
matching rapl_defaults as platform_data.
* Update MSR driver probe to assign pdev->dev.platform_data to
priv->defaults.
* Update Atom helper functions to use rp->lead_cpu directly for MSR
reads/writes instead of the generic get_rid().
* Update Atom floor frequency logic to access defaults via the
package private data pointer.
* Convert MSR device creation from fs_initcall() to module_init().
This preserves existing enumeration behavior as the driver was
already using module_init().
* Since rapl_ids need to exist after boot, remove __initconst
specifier.
No functional changes are expected.
Co-developed-by: Zhang Rui <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Acked-by: Srinivas Pandruvada <[email protected]>
Link: https://patch.msgid.link/20260331211950.3329932-2-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
TPMI-specific RAPL defaults differ from those used by MSR and MMIO
interfaces. Keeping them in RAPL common driver introduces unnecessary
complexity.
Move the TPMI defaults into the TPMI interface driver. This change
includes the following updates:
1. Add a TPMI-local struct rapl_defaults instance and assign it to
priv->defaults during TPMI probe.
2. Move rapl_check_unit_tpmi() and related unit-field definitions from
the common driver into the TPMI driver.
3. In rapl_check_unit_tpmi(), replace the generic get_rid() usage with
direct access to the TPMI package ID, since the function is now
interface-specific.
No functional changes are intended.
Co-developed-by: Zhang Rui <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Acked-by: Srinivas Pandruvada <[email protected]>
Link: https://patch.msgid.link/20260212233044.329790-10-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
RAPL default settings vary across different RAPL interfaces (MSR, TPMI,
MMIO). Currently, these defaults are stored in the common RAPL driver,
which requires interface-specific handling logic and makes the common
layer unnecessarily complex. There is no strong reason for the common
code to own these defaults, since they are inherently
interface-specific.
To prepare for moving default configuration into the individual
interface drivers,
1. Move struct rapl_defaults into a shared header so that interface
drivers can directly populate their own default settings.
2. Change the @defaults field in struct rapl_if_priv from void * to
const struct rapl_defaults * to improve type safety and readability
and update the common driver to use the typed defaults structure.
3. Update all internal getter functions and local pointers to use
const struct rapl_defaults * to maintain const-correctness.
4. Rename and export the common helper functions (check_unit,
set_floor_freq, compute_time_window) so interface drivers may
reuse or override them as appropriate.
No functional changes. This is a preparatory refactoring to allow
interface drivers to supply their own RAPL default settings.
Co-developed-by: Zhang Rui <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Acked-by: Srinivas Pandruvada <[email protected]>
Link: https://patch.msgid.link/20260212233044.329790-9-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
Replace hardcoded numeric constants with standard unit conversion
macros from linux/units.h for better code clarity and
self-documentation.
Add MICROJOULE_PER_JOULE and NANOJOULE_PER_JOULE to units.h to
support energy unit conversions, following the existing pattern
for power units.
No functional changes.
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Acked-by: Srinivas Pandruvada <[email protected]>
Link: https://patch.msgid.link/20260212233044.329790-8-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
Cleanup of the intel_rapl common driver requires introducing additional
exported helper and lifecycle functions. Before adding new exports,
create a dedicated symbol namespace for intel_rapl and update the
relevant interface drivers to explicitly import it.
This makes the intended usage of these symbols explicit, avoids
polluting the global namespace, and prepares the codebase for the
ongoing RAPL refactoring.
No functional changes are intended.
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Acked-by: Srinivas Pandruvada <[email protected]>
Link: https://patch.msgid.link/20260212233044.329790-2-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
This converts some of the visually simpler cases that have been split
over multiple lines. I only did the ones that are easy to verify the
resulting diff by having just that final GFP_KERNEL argument on the next
line.
Somebody should probably do a proper coccinelle script for this, but for
me the trivial script actually resulted in an assertion failure in the
middle of the script. I probably had made it a bit _too_ trivial.
So after fighting that far a while I decided to just do some of the
syntactically simpler cases with variations of the previous 'sed'
scripts.
The more syntactically complex multi-line cases would mostly really want
whitespace cleanup anyway.
Signed-off-by: Linus Torvalds <[email protected]>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <[email protected]>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <[email protected]>
On partitioned systems, multiple TPMI instances may exist per package,
but RAPL registers are only valid on one instance since RAPL has
package-scope control. Other instances return invalid versions during
domain parsing, which is expected behavior on such systems.
Currently this generates a firmware bug warning:
intel_rapl_tpmi: [Firmware Bug]: Invalid version
Remove the FW_BUG tag, downgrade to pr_debug(), and update the message
to clarify that invalid versions are expected on partitioned systems
where only one instance can be valid.
Fixes: 9eef7f9da9 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver")
Reported-by: Zhang Rui <[email protected]>
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Reviewed-by: Srinivas Pandruvada <[email protected]>
Link: https://patch.msgid.link/20260211223401.1575776-1-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
Currently, the RAPL PMU cpumask only includes one CPU per package
(typically the lead_cpu) for both MSR and TPMI interfaces. This
forces tools to pin their operations to that specific CPU, even
though package-scoped registers are readable from any CPU within
the package.
Change the cpumask to include all online CPUs in each package. This
allows tools like perf and turbostat to read RAPL events from any
CPU in the package without requiring special handling to find and
use the designated lead_cpu.
The change refactors get_pmu_cpu() into set_pmu_cpumask() which
populates the cpumask with all CPUs belonging to each RAPL package
instead of returning a single CPU.
This improves flexibility for userspace tools while maintaining
correctness since package-scoped RAPL MSRs are architecturally
accessible from any CPU in the package.
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Tested-by: Furquim Ulisses <[email protected]>
Reviewed-by: Srinivas Pandruvada <[email protected]>
Link: https://patch.msgid.link/20260209234310.1440722-3-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
The RAPL MSR read path incorrectly validates CPU context when called
from the PMU subsystem:
if (atomic) {
if (unlikely(smp_processor_id() != cpu))
return -EIO;
rdmsrq(ra->reg.msr, ra->value);
}
This check fails for package-scoped MSRs like RAPL energy counters,
which are readable from any CPU within the package.
The perf tool avoids hitting this check by validating against
/sys/bus/event_source/devices/power/cpumask before opening events.
However, turbostat does not perform this validation and may attempt
reads from non-lead CPUs, causing the check to fail and return zero
power values.
Since package-scoped MSRs are architecturally accessible from any CPU
in the package, remove the CPU matching check.
Also rename 'atomic' to 'pmu_ctx' to clarify this indicates PMU context
where rdmsrq() can be used directly instead of rdmsrl_safe_on_cpu().
Fixes: 748d6ba43a ("powercap: intel_rapl: Enable MSR-based RAPL PMU support")
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Tested-by: Furquim Ulisses <[email protected]>
Reviewed-by: Srinivas Pandruvada <[email protected]>
Link: https://patch.msgid.link/20260209234310.1440722-2-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
Replace all sprintf() calls with sysfs_emit() in sysfs show functions.
sysfs_emit() is preferred over sprintf() for formatting sysfs output
as it provides better bounds checking and prevents potential buffer
overflows.
Also, replace sprintf() with sysfs_emit() in show_constraint_name()
and simplify the code by removing the redundant strlen() call since
sysfs_emit() returns the length.
Signed-off-by: Sumeet Pawnikar <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Fix inconsistent error handling for sscanf() return value check.
Implicit boolean conversion is used instead of explicit return
value checks. The code checks if (!sscanf(...)) which is incorrect
because:
1. sscanf returns the number of successfully parsed items
2. On success, it returns 1 (one item passed)
3. On failure, it returns 0 or EOF
4. The check 'if (!sscanf(...))' is wrong because it treats
success (1) as failure
All occurrences of sscanf() now uses explicit return value check.
With this behavior it returns '-EINVAL' when parsing fails (returns
0 or EOF), and continues when parsing succeeds (returns 1).
Signed-off-by: Sumeet Pawnikar <[email protected]>
[ rjw: Subject and changelog edits ]
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
The device becomes visible to userspace via device_register()
even before it fully initialized by idr_init(). If userspace
or another thread tries to register a zone immediately after
device_register(), the control_type_valid() will fail because
the control_type is not yet in the list. The IDR is not yet
initialized, so this race condition causes zone registration
failure.
Move idr_init() and list addition before device_register()
fix the race condition.
Signed-off-by: Sumeet Pawnikar <[email protected]>
[ rjw: Subject adjustment, empty line added ]
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Pull devicetree updates from Rob Herring:
"DT bindings:
- Convert lattice,ice40-fpga-mgr, apm,xgene-storm-dma,
brcm,sr-thermal, amazon,al-thermal, brcm,ocotp, mt8173-mdp, Actions
Owl SPS, Marvell AP80x System Controller, Marvell CP110 System
Controller, cznic,moxtet, and apm,xgene-slimpro-mbox to DT schema
format
- Add i.MX95 fsl,irqsteer, MT8365 Mali Bifrost GPU, Anvo ANV32C81W
EEPROM, and Microchip pic64gx PLIC
- Add missing LGE, AMD Seattle, and APM X-Gene SoC platform
compatibles
- Updates to brcm,bcm2836-l1-intc, brcm,bcm2835-hvs, and bcm2711-hdmi
bindings to fix warnings on BCM2712 platforms
- Drop obsolete db8500-thermal.txt
- Treewide clean-up of extra blank lines and inconsistent quoting
- Ensure all .dtbo targets are applied to a base .dtb
- Speed up dt_binding_check by skipping running validation on empty
examples
DT core:
- Add of_machine_device_match() and of_machine_get_match_data()
helpers and convert users treewide
- Fix bounds checking of address properties in FDT code. Rework the
code to have a single implementation of the bounds checks.
- Rework of_irq_init() to ignore any implicit interrupt-parent (i.e.
in a parent node) on nodes without an interrupt. This matches the
spec description and fixes some RISC-V platforms.
- Avoid a spurious message on overlay removal
- Skip DT kunit tests on RISCV+ACPI"
* tag 'devicetree-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (55 commits)
dt-bindings: kbuild: Skip validating empty examples
dt-bindings: interrupt-controller: brcm,bcm2836-l1-intc: Drop interrupt-controller requirement
dt-bindings: display: Fix brcm,bcm2835-hvs bindings for BCM2712
dt-bindings: display: bcm2711-hdmi: Add interrupt details for BCM2712
of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root node
soc: tegra: Simplify with of_machine_device_match()
soc: qcom: ubwc: Simplify with of_machine_get_match_data()
powercap: dtpm: Simplify with of_machine_get_match_data()
platform: surface: Simplify with of_machine_get_match_data()
irqchip/atmel-aic: Simplify with of_machine_get_match_data()
firmware: qcom: scm: Simplify with of_machine_device_match()
cpuidle: big_little: Simplify with of_machine_device_match()
cpufreq: sun50i: Simplify with of_machine_device_match()
cpufreq: mediatek: Simplify with of_machine_get_match_data()
cpufreq: dt-platdev: Simplify with of_machine_get_match_data()
of: Add wrappers to match root node with OF device ID tables
dt-bindings: eeprom: at25: Add Anvo ANV32C81W
of/reserved_mem: Simplify the logic of __reserved_mem_alloc_size()
of/reserved_mem: Simplify the logic of fdt_scan_reserved_mem_reg_nodes()
of/reserved_mem: Simplify the logic of __reserved_mem_reserve_reg()
...
Currently, RAPL PMU support requires adding CPU model entries to
arch/x86/events/rapl.c for each new generation. However, RAPL MSRs are
not architectural and require platform-specific customization, making
arch/x86 an inappropriate location for this functionality.
The powercap subsystem already handles RAPL functionality and is the
natural place to consolidate all RAPL features. The powercap RAPL
driver already includes PMU support for TPMI-based RAPL interfaces,
making it straightforward to extend this support to MSR-based RAPL
interfaces as well.
This consolidation eliminates the need to maintain RAPL support in
multiple subsystems and provides a unified approach for both TPMI and
MSR-based RAPL implementations.
The MSR-based PMU support includes the following updates:
1. Register MSR-based PMU support for the supported platforms
and unregister it when no online CPUs remain in the package.
2. Remove existing checks that restrict RAPL PMU support to TPMI-based
interfaces and extend the logic to allow MSR-based RAPL interfaces.
3. Define a CPU model list to determine which processors should
register RAPL PMU interface through the powercap driver for
MSR-based RAPL, excluding those that support TPMI interface.
This list prevents conflicts with existing arch/x86 PMU code
that already registers RAPL PMU for some processors. Add
Panther Lake & Wildcat Lake to the CPU models list.
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Reviewed-by: Srinivas Pandruvada <[email protected]>
[ rjw: Changelog edits ]
Link: https://patch.msgid.link/20251121000539.386069-3-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
The current read_raw() implementation of the TPMI, MMIO and MSR
interfaces does not distinguish between atomic and non-atomic callers.
rapl_msr_read_raw() uses rdmsrq_safe_on_cpu(), which can sleep and
issue cross CPU calls. When MSR-based RAPL PMU support is enabled, PMU
event handlers can invoke this function from atomic context where
sleeping or rescheduling is not allowed. In atomic context, the caller
is already executing on the target CPU, so a direct rdmsrq() is
sufficient.
To support such usage, introduce an atomic flag to the read_raw()
interface to allow callers pass the context information. Modify the
common RAPL code to propagate this flag, and set the flag to reflect
the calling contexts.
Utilize the atomic flag in rapl_msr_read_raw() to perform direct MSR
read with rdmsrq() when running in atomic context, and a sanity check
to ensure target CPU matches the current CPU for such use cases.
The TPMI and MMIO implementations do not require special atomic
handling, so the flag is ignored in those paths.
This is a preparatory patch for adding MSR-based RAPL PMU support.
Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]>
Reviewed-by: Srinivas Pandruvada <[email protected]>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/20251121000539.386069-2-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <[email protected]>
Convert values in microseconds to ktime using us_to_ktime() instead of
multiplying them by NSEC_PER_USEC and using ns_to_ktime() for the
conversion.
Signed-off-by: Xichao Zhao <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
The get_pd_power_uw() function can crash with a NULL pointer dereference
when em_cpu_get() returns NULL. This occurs when a CPU becomes impossible
during runtime, causing get_cpu_device() to return NULL, which propagates
through em_cpu_get() and leads to a crash when em_span_cpus() dereferences
the NULL pointer.
Add a NULL check after em_cpu_get() and return 0 if unavailable,
matching the existing fallback behavior in __dtpm_cpu_setup().
Fixes: eb82bace89 ("powercap/drivers/dtpm: Scale the power with the load")
Signed-off-by: Sivan Zohar-Kotzer <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Drop an excess empty code line ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
The TPMI platform information provides a mapping of OOBMSM PCI devices to
logical CPUs. Since this mapping is consistent across all OOBMSM features
(e.g., TPMI, PMT, SDSi), it can be leveraged by multiple drivers. To
facilitate reuse, relocate the struct intel_tpmi_plat_info to intel_vsec.h,
renaming it to struct oobmsm_plat_info, making it accessible to other
features. While modifying headers, place them in alphabetical order.
Signed-off-by: David E. Box <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ilpo Järvinen <[email protected]>
Add Bartlett Lake to the list of supported processors in the RAPL
common driver.
Acked-by: Zhang Rui <[email protected]>
Signed-off-by: Qiao Wei <[email protected]>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
PL1 cannot be disabled on some platforms. The ENABLE bit is still set
after software clears it. This behavior leads to a scenario where, upon
user request to disable the Power Limit through the powercap sysfs, the
ENABLE bit remains set while the CLAMPING bit is inadvertently cleared.
According to the Intel Software Developer's Manual, the CLAMPING bit,
"When set, allows the processor to go below the OS requested P states in
order to maintain the power below specified Platform Power Limit value."
Thus this means the system may operate at higher power levels than
intended on such platforms.
Enhance the code to check ENABLE bit after writing to it, and stop
further processing if ENABLE bit cannot be changed.
Reported-by: Srinivas Pandruvada <[email protected]>
Fixes: 2d281d8196 ("PowerCap: Introduce Intel RAPL power capping driver")
Cc: All applicable <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: Use str_enabled_disabled() instead of open-coded equivalent ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Linus Torvalds