kernel/linux.git/drivers/powercap, branch v6.19.11

powercap: intel_rapl: Add PL4 support for Ice Lake

2026-03-04T12:19:38+00:00

[ Upstream commit 54b3cd55a515c7c0fcfa0c1f0b10d62c11d64bcc ] Microsoft Surface Pro 7 firmware throttles the processor upon boot/resume. Userspace needs to be able to restore the correct value. Link: https://github.com/linux-surface/linux-surface/issues/706 Signed-off-by: Daniel Tang Link: https://patch.msgid.link/6088605.ChMirdbgyp@daniel-desktop3 Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

powercap: intel_rapl_tpmi: Remove FW_BUG from invalid version check

2026-02-26T23:01:28+00:00

[ Upstream commit c7d54dafa042cf379859dba265fe5afef6fa8770 ] 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: 9eef7f9da928 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver") Reported-by: Zhang Rui Signed-off-by: Kuppuswamy Sathyanarayanan Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260211223401.1575776-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

powercap: intel_rapl: Remove incorrect CPU check in PMU context

2026-02-26T23:01:28+00:00

[ Upstream commit 7537bae8b6eb635583e0e6260f61d13ddbd52087 ] 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: 748d6ba43afd ("powercap: intel_rapl: Enable MSR-based RAPL PMU support") Signed-off-by: Kuppuswamy Sathyanarayanan Tested-by: Furquim Ulisses Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260209234310.1440722-2-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

powercap: intel_rapl: Fix possible recursive lock warning

2025-12-17T16:24:28+00:00

With the RAPL PMU addition, there is a recursive locking when CPU online callback function calls rapl_package_add_pmu(). Here cpu_hotplug_lock is already acquired by cpuhp_thread_fun() and rapl_package_add_pmu() tries to acquire again. <4>[ 8.197433] ============================================ <4>[ 8.197437] WARNING: possible recursive locking detected <4>[ 8.197440] 6.19.0-rc1-lgci-xe-xe-4242-05b7c58b3367dca84+ #1 Not tainted <4>[ 8.197444] -------------------------------------------- <4>[ 8.197447] cpuhp/0/20 is trying to acquire lock: <4>[ 8.197450] ffffffff83487870 (cpu_hotplug_lock){++++}-{0:0}, at: rapl_package_add_pmu+0x37/0x370 [intel_rapl_common] <4>[ 8.197463] but task is already holding lock: <4>[ 8.197466] ffffffff83487870 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x6d/0x290 <4>[ 8.197477] other info that might help us debug this: <4>[ 8.197480] Possible unsafe locking scenario: <4>[ 8.197483] CPU0 <4>[ 8.197485] ---- <4>[ 8.197487] lock(cpu_hotplug_lock); <4>[ 8.197490] lock(cpu_hotplug_lock); <4>[ 8.197493] *** DEADLOCK *** .. .. <4>[ 8.197542] __lock_acquire+0x146e/0x2790 <4>[ 8.197548] lock_acquire+0xc4/0x2c0 <4>[ 8.197550] ? rapl_package_add_pmu+0x37/0x370 [intel_rapl_common] <4>[ 8.197556] cpus_read_lock+0x41/0x110 <4>[ 8.197558] ? rapl_package_add_pmu+0x37/0x370 [intel_rapl_common] <4>[ 8.197561] rapl_package_add_pmu+0x37/0x370 [intel_rapl_common] <4>[ 8.197565] rapl_cpu_online+0x85/0x87 [intel_rapl_msr] <4>[ 8.197568] ? __pfx_rapl_cpu_online+0x10/0x10 [intel_rapl_msr] <4>[ 8.197570] cpuhp_invoke_callback+0x41f/0x6c0 <4>[ 8.197573] ? cpuhp_thread_fun+0x6d/0x290 <4>[ 8.197575] cpuhp_thread_fun+0x1e2/0x290 <4>[ 8.197578] ? smpboot_thread_fn+0x26/0x290 <4>[ 8.197581] smpboot_thread_fn+0x12f/0x290 <4>[ 8.197584] ? __pfx_smpboot_thread_fn+0x10/0x10 <4>[ 8.197586] kthread+0x11f/0x250 <4>[ 8.197589] ? __pfx_kthread+0x10/0x10 <4>[ 8.197592] ret_from_fork+0x344/0x3a0 <4>[ 8.197595] ? __pfx_kthread+0x10/0x10 <4>[ 8.197597] ret_from_fork_asm+0x1a/0x30 <4>[ 8.197604] Fix this issue in the same way as rapl powercap package domain is added from the same CPU online callback by introducing another interface which doesn't call cpus_read_lock(). Add rapl_package_add_pmu_locked() and rapl_package_remove_pmu_locked() which don't call cpus_read_lock(). Fixes: 748d6ba43afd ("powercap: intel_rapl: Enable MSR-based RAPL PMU support") Reported-by: Borah, Chaitanya Kumar Closes: https://lore.kernel.org/linux-pm/5427ede1-57a0-43d1-99f3-8ca4b0643e82@intel.com/T/#u Tested-by: Kuppuswamy Sathyanarayanan Tested-by: RavitejaX Veesam Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20251217153455.3560176-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki

powercap: fix sscanf() error return value handling

2025-12-15T11:33:59+00:00

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 [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20251207151549.202452-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki

powercap: fix race condition in register_control_type()

2025-12-15T11:29:11+00:00

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 [ rjw: Subject adjustment, empty line added ] Link: https://patch.msgid.link/20251205190216.5032-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki

Merge tag 'devicetree-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

2025-12-04T23:50:37+00:00

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() ...

powercap: dtpm: Simplify with of_machine_get_match_data()

2025-11-27T01:43:02+00:00

Replace open-coded getting root OF node, matching against it and getting the match data with new of_machine_get_match_data() helper. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Lukasz Luba Reviewed-by: AngeloGioacchino Del Regno Tested-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-9-d46b72003fd6@linaro.org Signed-off-by: Rob Herring (Arm)

powercap: intel_rapl: Enable MSR-based RAPL PMU support

2025-11-21T20:47:08+00:00

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 Reviewed-by: Srinivas Pandruvada [ rjw: Changelog edits ] Link: https://patch.msgid.link/20251121000539.386069-3-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki

powercap: intel_rapl: Prepare read_raw() interface for atomic-context callers

2025-11-21T20:47:08+00:00

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 Reviewed-by: Srinivas Pandruvada [ rjw: Subject tweak ] Link: https://patch.msgid.link/20251121000539.386069-2-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki