JIRA: https://redhat.atlassian.net/browse/RHEL-174711
commit d2bf45d067c728b0fe6e8f99a7386b8291e391e3
Author: Aaron Tomlin <atomlin@atomlin.com>
Date: Tue Mar 24 20:11:59 2026 -0400
fs/resctrl: Add "*" shorthand to set io_alloc CBM for all domains
Configuring the io_alloc_cbm interface requires an explicit domain ID for each
cache domain. On systems with high core counts and numerous cache clusters,
this requirement becomes cumbersome for automation and management tasks that
aim to apply a uniform policy.
Introduce a wildcard domain ID selector "*" for the io_alloc_cbm interface.
This enables users to set the same Capacity Bitmask (CBM) across all cache
domains in a single operation.
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Babu Moger <babu.moger@amd.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Link: https://patch.msgid.link/20260325001159.447075-3-atomlin@atomlin.com
(cherry picked from commit d2bf45d067c728b0fe6e8f99a7386b8291e391e3)
Assisted-by: Patchpal
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-174711
commit d06b8e7c97c3290e61006e30b32beb9e715fab82
Author: Aaron Tomlin <atomlin@atomlin.com>
Date: Tue Mar 24 20:11:58 2026 -0400
fs/resctrl: Report invalid domain ID when parsing io_alloc_cbm
The last_cmd_status file is intended to report details about the most recent
resctrl filesystem operation, specifically to aid in diagnosing failures.
However, when parsing io_alloc_cbm, if a user provides a domain ID that does
not exist in the resource, the operation fails with -EINVAL without updating
last_cmd_status. This results in inconsistent behaviour where the system call
returns an error, but last_cmd_status misleadingly reports "ok", leaving the
user unaware that the failure was caused by an invalid domain ID.
Write an error message to last_cmd_status when the target domain ID cannot
be found.
Fixes: 28fa2cce7a83 ("fs/resctrl: Introduce interface to modify io_alloc capacity bitmasks")
Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Babu Moger <babu.moger@amd.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Link: https://patch.msgid.link/20260325001159.447075-2-atomlin@atomlin.com
(cherry picked from commit d06b8e7c97c3290e61006e30b32beb9e715fab82)
Assisted-by: Patchpal
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-239086
commit a213dfaa2596c1c0dc4dae91c14fbfa499c03223
Author: Breno Leitao <leitao@debian.org>
Date: Mon Aug 3 02:47:40 2026 -0700
x86/mce: Set up the polling timer before CMCI discovery
I hit the following on one of my machines:
mce: CPU0 BANK15 CMCI inherited storm
------------[ cut here ]------------
ODEBUG: assert_init not available (active state 0) object: (____ptrval____) object type: timer_list hint: 0x0
WARNING: lib/debugobjects.c:632 at debug_object_assert_init+0x178/0x230, CPU#0: swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #3 PREEMPTLAZY
RIP: 0010:debug_object_assert_init+0x18f/0x230
Call Trace:
<TASK>
__mod_timer
mce_timer_kick
cmci_discover
intel_init_cmci
mce_intel_feature_init
mcheck_cpu_init
identify_cpu
identify_boot_cpu
arch_cpu_finalize_init
start_kernel
A second splat follows right after, from timer_setup() finding that same
timer already queued:
ODEBUG: init active (active state 0) object: (____ptrval____) object type: timer_list hint: stub_timer+0x0/0x10
This is happening because CMCI storm detection is trying to modify the timer
before latter was properly set up.
Set up the timer first. __mcheck_cpu_setup_timer() only calls timer_setup(),
and depends on neither the generic nor the vendor init.
[ bp: Massage commit message. ]
Fixes: 1f68ce2a02 ("x86/mce: Handle Intel threshold interrupt storms")
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260803-mce_timer_init-v1-1-9539db424330@debian.org
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-226828
CVE: CVE-2026-43332
commit 9e07e3b81807edd356e1f794cffa00a428eff443
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Wed Apr 1 16:33:53 2026 +0200
thermal: core: Fix thermal zone device registration error path
If thermal_zone_device_register_with_trips() fails after registering
a thermal zone device, it needs to wait for the tz->removal completion
like thermal_zone_device_unregister(), in case user space has managed
to take a reference to the thermal zone device's kobject, in which case
thermal_release() may not be called by the error path itself and tz may
be freed prematurely.
Add the missing wait_for_completion() call to the thermal zone device
registration error path.
Fixes: 04e6ccfc93 ("thermal: core: Fix NULL pointer dereference in zone registration error path")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Tested-by: Lukasz Luba <lukasz.luba@arm.com>
Link: https://patch.msgid.link/2849815.mvXUDI8C0e@rafael.j.wysocki
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222908
CVE: CVE-2026-64279
commit b1a58ed9eab146b36f41a55db8f5d7ce9fdedf3f
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 11 16:37:13 2026 +0200
i2c: core: fix adapter deregistration race
Adapters can be looked up by their id using i2c_get_adapter() which
takes a reference to the embedded struct device.
Remove the adapter from the IDR before tearing it down during
deregistration (and on registration failure) to make sure its resources
are not accessed after having been freed (e.g. the device name).
Fixes: 35fc37f818 ("i2c: Limit core locking to the necessary sections")
Cc: stable@vger.kernel.org # 2.6.31
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222908
CVE: CVE-2026-64279
commit 3e2041ea586ae37fcea918ecb505ab9972a1201d
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 11 16:37:11 2026 +0200
i2c: core: disable runtime PM on adapter registration failure
Runtime PM is disabled by driver core when deregistering a device (and
on registration failure) but add an explicit disable to balance the
enable call when adapter registration fails for symmetry.
Fixes: 23a698fe65 ("i2c: core: treat EPROBE_DEFER when acquiring SCL/SDA GPIOs")
Cc: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222908
CVE: CVE-2026-64279
commit 07d5fb537928aad4369aaff0cbae73ba38a719af
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 11 16:37:10 2026 +0200
i2c: core: fix adapter debugfs creation
Clients can be registered from bus notifier callbacks so the debugfs
directory needs to be created before registering the adapter as clients
use that directory as their debugfs parent.
Move debugfs creation before adapter registration to avoid having
clients create their debugfs directories in the debugfs root (which is
also more likely to fail due to name collisions).
Note that failure to allocate the adapter name must now be handled
explicitly as debugfs_create_dir() cannot handle a NULL name (unlike
device_add() which returns an error).
Fixes: 73febd775b ("i2c: create debugfs entry per adapter")
Cc: stable@vger.kernel.org # 6.8
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222908
CVE: CVE-2026-64279
commit 158efa411c57111d87bf265a3776614f32d70007
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 11 16:37:09 2026 +0200
i2c: core: fix adapter probe deferral loop
Drivers must not probe defer after having registered devices as that
will trigger a probe loop if the devices bind to a driver (cf. commit
fbc35b45f9 ("Add documentation on meaning of -EPROBE_DEFER")).
Move the recovery initialisation, where the GPIO lookup may fail, before
registering the adapter to prevent this.
Fixes: 75820314de ("i2c: core: add generic I2C GPIO recovery")
Cc: stable@vger.kernel.org # 5.9
Cc: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222908
CVE: CVE-2026-64279
commit 2295d2bb101faa663fbc45fadbb3fec45f107441
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 11 16:37:08 2026 +0200
i2c: core: fix NULL-deref on adapter registration failure
If adapter registration ever fails the release callback would trigger a
NULL-pointer dereference as the completion struct has not been
initialised.
Note that before the offending commit this would instead have resulted
in a minor memory leak of the adapter name.
Fixes: 3f8c4f5e9a57 ("i2c: core: fix reference leak in i2c_register_adapter()")
Cc: stable@vger.kernel.org
Cc: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222908
CVE: CVE-2026-64279
commit 3c7e164344e5bcf6f274bbf59a3274f5caad9bc1
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 11 16:37:07 2026 +0200
i2c: core: fix hang on adapter registration failure
Clients may be registered from bus notifier callbacks when the adapter
is registered. On a subsequent error during registration, the adapter
references taken by such clients prevent the wait for the references to
be released from ever completing.
Fix this by refactoring client deregistration and deregistering also on
late adapter registration failures.
Fixes: f8756c67b3 ("i2c: core: call of_i2c_setup_smbus_alert in i2c_register_adapter")
Cc: stable@vger.kernel.org # 4.15
Cc: Phil Reid <preid@electromag.com.au>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222908
CVE: CVE-2026-64279
commit 8ce19524e4cc2462685f596a6402fbd8fb984ab2
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 11 16:37:06 2026 +0200
i2c: core: fix irq domain leak on adapter registration failure
Make sure to tear down the host notify irq domain on adapter
registration failure to avoid leaking it.
This issue was flagged by Sashiko when reviewing another adapter
registration fix.
Fixes: 4d5538f588 ("i2c: use an IRQ to report Host Notify events, not alert")
Cc: stable@vger.kernel.org # 4.10
Cc: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222908
CVE: CVE-2026-64279
commit 3f8c4f5e9a57868fa107016c81165686d23325f2
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date: Wed Dec 11 12:08:03 2024 +0900
i2c: core: fix reference leak in i2c_register_adapter()
The reference count of the device incremented in device_initialize() is
not decremented when device_add() fails. Add a put_device() call before
returning from the function.
This bug was found by an experimental static analysis tool that I am
developing.
Fixes: 60f6859702 ("i2c: core: Setup i2c_adapter runtime-pm before calling device_add()")
Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-222295
commit f112ea910e554d58b4b39a4492b7d302f0f4204f
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date: Sun Jul 5 18:12:59 2026 +0300
mei: bus: access mei_device under device_lock on cleanup
Fix couple of problems in mei_cl_bus_dev_release():
mei_cl_flush_queues() is running without lock.
bus->file_list access after mei_dev_bus_put(bus) can become a
use-after-free if this was the last reference to bus.
Protect queues cleanup and WARN traversal by device lock there
to avoid the concurrent access problems.
Move WARN traversal before mei_dev_bus_put(bus).
This file uses bus variable name for mei_device, adjust
code of mei_cl_bus_dev_release() to use bus variable too.
Cc: stable <stable@kernel.org>
Fixes: 35e8a426b16a ("mei: bus: Check for still connected devices in mei_cl_bus_dev_release()")
Reviewed-by: Menachem Adin <menachem.adin@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Link: https://patch.msgid.link/20260705151259.3054795-1-alexander.usyskin@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-220528
commit 54b603f2db6b95495bc33a8f2bde80f044baff9a
Author: Yaxiong Tian <tianyaxiong@kylinos.cn>
Date: Tue Dec 30 14:15:34 2025 +0800
PM: EM: Fix incorrect description of the cost field in struct em_perf_state
Due to commit 1b600da510 ("PM: EM: Optimize em_cpu_energy() and remove
division"), the logic for energy consumption calculation has been modified.
The actual calculation of cost is 10 * power * max_frequency / frequency
instead of power * max_frequency / frequency.
Therefore, the comment for cost has been updated to reflect the correct
content.
Fixes: 1b600da510 ("PM: EM: Optimize em_cpu_energy() and remove division")
Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
[ rjw: Added Fixes: tag ]
Link: https://patch.msgid.link/20251230061534.816894-1-tianyaxiong@kylinos.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-212012
commit ffe8a0c6b55285ceaf2f42fc20c3a0594d14f1e9
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon Jul 20 11:28:44 2026 -0500
pinctrl-amd: Don't clear S4 wake bits at probe
commit 6bc3462a0f ("pinctrl: amd: Mask wake bits on probe again")
introduced a regression where Wake-on-LAN no longer works after suspend
or shutdown on some AMD platforms.
Firmware-programmed S4 wake bits for devices like PCIe NICs using PCI
PME are cleared at probe, but nothing restores them. Unlike S0i3/S3 wake
sources that use enable_irq_wake() -> amd_gpio_irq_set_wake(), PCIe PME
does not use GPIO IRQ infrastructure and relies on firmware configuration.
The original intent of commit 6bc3462a0f ("pinctrl: amd: Mask wake
bits on probe again") was to clear spurious wake bits left by firmware
to prevent unwanted wakeups. However, S4 wake bits are used for
hardware-level wake sources like WoL that bypass the kernel's IRQ wake
API.
Fix by preserving S4 wake bits at probe and only clearing S0i3/S3 bits:
- Firmware-configured S4 wake sources (WoL) continue working
- Kernel maintains control of S3/S0i3 wake policy via set_wake()
- S3-only wake sources work correctly per commit f31f33dbb3ba ("pinctrl:
amd: Take suspend type into consideration which pins are non-wake")
The trade-off is that firmware-programmed spurious S4 wake bits remain
set, but this is less problematic than breaking WoL.
Fixes: 6bc3462a0f ("pinctrl: amd: Mask wake bits on probe again")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-214504
commit 607af438e6430893a822964c841a1994b33acccc
Author: Ali Ahmet MEMIS <dev@unknownbbqr.xyz>
Date: Sun Apr 26 08:09:28 2026 -0700
tools/power/x86/intel-speed-select: Harden daemon pidfile open
Avoid symlink-based pidfile clobbering by opening the pidfile with
O_NOFOLLOW and validating it with fstat() before locking/writing.
The daemon currently uses a fixed pidfile path under /tmp. A local
unprivileged user can pre-create a symlink at that path and cause a
root-run daemon instance to write into an attacker-chosen file.
Fixes: 7fd786dfbd ("tools/power/x86/intel-speed-select: OOB daemon mode")
Signed-off-by: Ali Ahmet MEMIS <dev@unknownbbqr.xyz>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-213934
commit 348ccc754d8939e21ca5956ff45720b81d6e407f
Author: Lukas Wunner <lukas@wunner.de>
Date: Thu May 14 07:40:42 2026 +0200
platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery
After a PCIe Uncorrectable Error has been reported by a device with
Intel Vendor Specific Extended Capabilities and has been recovered
through a Secondary Bus Reset, its driver calls intel_vsec_pci_probe()
to rescan and reinitialize VSECs.
intel_vsec_pci_probe() invokes pcim_enable_device() and thereby adds
another devm action which calls pcim_disable_device() on driver unbind.
So once the driver unbinds, pcim_disable_device() will be called as many
times as an Uncorrectable Error occurred, plus one. This will lead to
an enable_cnt imbalance on driver unbind.
Additionally, since commit dc957ab6aa05 ("platform/x86/intel/vsec: Add
private data for per-device data"), a devm_kzalloc() allocation is
leaked on every Uncorrectable Error.
Avoid by splitting the VSEC rescan out of intel_vsec_pci_probe() into a
separate helper and calling that on PCIe error recovery.
Fixes: 936874b77d ("platform/x86/intel/vsec: Add PCI error recovery support to Intel PMT")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v6.0+
Link: https://patch.msgid.link/bd594d09fa866dc51dddc9a447c3b23f9b1402cc.1778736835.git.lukas@wunner.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-213934
Conflicts:
- drivers/platform/x86/intel/vsec.c: minor fix up add const in intel_vsec_register_device
commit 9577c74c96f88d807d1ba005adbf5952e7127e55
Author: David E. Box <david.e.box@linux.intel.com>
Date: Thu Mar 12 18:51:41 2026 -0700
platform/x86/intel/vsec: Make driver_data info const
Treat PCI id->driver_data (intel_vsec_platform_info) as read-only by making
vsec_priv->info a const pointer and updating all function signatures to
accept const intel_vsec_platform_info *.
This improves const-correctness and clarifies that the platform info data
from the driver_data table is not meant to be modified at runtime.
No functional changes intended.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patch.msgid.link/20260313015202.3660072-3-david.e.box@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
(cherry picked from commit 9577c74c96f88d807d1ba005adbf5952e7127e55)
Assisted-by: Patchpal AI
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-213537
commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9
Author: Chang S. Bae <chang.seok.bae@intel.com>
Date: Mon Jun 9 17:16:59 2025 -0700
x86/fpu: Ensure XFD state on signal delivery
Sean reported [1] the following splat when running KVM tests:
WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70
Call Trace:
<TASK>
fpu__clear_user_states+0x9c/0x100
arch_do_signal_or_restart+0x142/0x210
exit_to_user_mode_loop+0x55/0x100
do_syscall_64+0x205/0x2c0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Chao further identified [2] a reproducible scenario involving signal
delivery: a non-AMX task is preempted by an AMX-enabled task which
modifies the XFD MSR.
When the non-AMX task resumes and reloads XSTATE with init values,
a warning is triggered due to a mismatch between fpstate::xfd and the
CPU's current XFD state. fpu__clear_user_states() does not currently
re-synchronize the XFD state after such preemption.
Invoke xfd_update_state() which detects and corrects the mismatch if
there is a dynamic feature.
This also benefits the sigreturn path, as fpu__restore_sig() may call
fpu__clear_user_states() when the sigframe is inaccessible.
[ dhansen: minor changelog munging ]
Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1]
Fixes: 672365477a ("x86/fpu: Update XFD state where required")
Reported-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Tested-by: Chao Gao <chao.gao@intel.com>
Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2]
Cc:stable@vger.kernel.org
Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com
(cherry picked from commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9)
Assisted-by: Patchpal
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-213294
commit c085d82613d5618814b84406c8b2d64f1bc305e7
Author: HyeongJun An <sammiee5311@gmail.com>
Date: Sat Jun 6 02:49:05 2026 +0900
platform/x86: intel-hid: Protect ACPI notify handler against recursion
Since commit e2ffcda162 ("ACPI: OSL: Allow Notify () handlers to run on
all CPUs") ACPI notify handlers like the intel-hid notify_handler() may
run on multiple CPU cores racing with themselves.
On convertibles and detachables (matched by DMI chassis-type 31 and 32 in
dmi_auto_add_switch[]) the SW_TABLET_MODE input device is registered
lazily from notify_handler() on the first tablet-mode event, via
intel_hid_switches_setup(). When two such events race on different CPUs
both can pass the !priv->switches check and register the priv->switches
input device twice, resulting in a duplicate sysfs entry and a subsequent
NULL pointer dereference.
This is the same class of bug fixed by commit e075c3b13a ("platform/x86:
intel-vbtn: Protect ACPI notify handler against recursion") for the
sibling intel-vbtn driver.
Protect intel-hid notify_handler() from racing with itself with a mutex
to fix this.
Fixes: e2ffcda162 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs")
Cc: stable@vger.kernel.org
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260605174905.131095-1-sammiee5311@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-212894
commit 27d80e0f8b8dff97503fc0061754b1d3800cb961
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Tue Jul 7 19:19:55 2026 +0200
cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()
Setting cpu->capacity_perf to cpu->pstate.max_pstate_physical in the
"no turbo" case is inconsistent with what happens elsewhere in the
driver and causes arch_scale_cpu_capacity() to be incorrect. It also
skews arch_scale_freq_capacity() which ends up differing from 1024 for
the guaranteed P-state.
Address that by setting capacity_perf to HWP_GUARANTEED_PERF() in the
"no turbo" case.
Fixes: 929ebc93cc ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: All applicable <stable@vger.kernel.org>
Link: https://patch.msgid.link/12928972.O9o76ZdvQC@rafael.j.wysocki
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-212369
commit b91d287fa7a1ba0727eed5823c6ee4924ee5fa31
Author: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Date: Sat Jun 13 15:17:47 2026 -0700
thermal: intel: Fix dangling resources on thermal_throttle_online() failure
The function thermal_throttle_add_dev() may fail and abort a CPU hotplug
online operation. Since the failure occurs within the online callback,
thermal_throttle_online(), the CPU hotplug framework does not invoke the
corresponding offline callback. As a result, the hardware and software
resources set up during the failed operation are not torn down.
Since only thermal_throttle_add_dev() can fail, call it before setting up
the rest of the resources.
Fixes: f6656208f0 ("x86/mce/therm_throt: Optimize notifications of thermal throttle")
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-1-3a26d1e47fc8@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-212368
commit 6b63520ed14b17bbe9c2103debbd2152dde1fba3
Author: Guixiong Wei <weiguixiong@bytedance.com>
Date: Tue Jun 2 10:07:52 2026 +0800
platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug
When the last CPU of a legacy uncore die goes offline,
uncore_freq_remove_die_entry() clears control_cpu. During CPU hotplug
re-add, uncore_freq_add_entry() still populates sysfs attributes before
assigning the new control CPU. As a result, the current frequency read
returns -ENXIO and current_freq_khz is omitted from the recreated sysfs
group.
Assign control_cpu before the initial read paths and before
create_attr_group() so sysfs recreation uses the new online CPU. If
sysfs creation fails, restore control_cpu to -1 to keep the error path
state consistent.
Fixes: 4d73c6772a ("platform/x86: intel-uncore-freq: Conditionally create attribute for read frequency")
Cc: stable@vger.kernel.org
Signed-off-by: Guixiong Wei <weiguixiong@bytedance.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260602020752.3126-1-weiguixiong@bytedance.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
(cherry picked from commit 6b63520ed14b17bbe9c2103debbd2152dde1fba3)
Assisted-by: Patchpal
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-212367
commit 10dd1a736d557e310a77117832874729a0175d57
Author: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Date: Tue May 12 17:35:34 2026 +0800
i2c: i801: fix hardware state machine corruption in error path
A severe livelock and subsequent Hung Task panic were observed in the
i2c-i801 driver during concurrent Fuzzing. The crash is caused by an
unconditional hardware register cleanup in the error handling path of
i801_access().
When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus
controller is actively used by BIOS/ACPI), the kernel does not actually
acquire the hardware ownership. However, the code jumps to the 'out'
label and executes:
iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv));
This forcefully clears the INUSE_STS lock and resets the hardware status
flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI
transactions and totally corrupts the SMBus hardware state machine.
Consequently, all subsequent i801_access() calls fail at the pre-check
stage, triggering an endless stream of "SMBus is busy, can't use it!"
error logs. Over a slow serial console, this printk flood monopolizes
the CPU (Console Livelock), starving other processes trying to acquire
the mmap_lock down_read semaphore, ultimately triggering the hung task
watchdog.
Fix this by moving the 'out' label below the hardware register cleanup.
If i801_check_pre() fails, we safely bypass the iowrite8() and only
release the software locks (pm_runtime and mutex), strictly adhering to
the rule of not releasing resources that were never acquired.
Fixes: 1f760b87e5 ("i2c: i801: Call i801_check_pre() from i801_access()")
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Cc: <stable@vger.kernel.org> # v6.3+
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260512093534.348655-1-w15303746062@163.com
(cherry picked from commit 10dd1a736d557e310a77117832874729a0175d57)
Assisted-by: Patchpal
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-211103
commit 05243d490bb7852a8acca7b5b5658019c7797a52
Author: Nikunj A Dadhania <nikunj@amd.com>
Date: Wed Mar 18 07:56:52 2026 +0000
x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling()
Move FSGSBASE enablement from identify_cpu() to cpu_init_exception_handling()
to ensure it is enabled before any exceptions can occur on both boot and
secondary CPUs.
== Background ==
Exception entry code (paranoid_entry()) uses ALTERNATIVE patching based on
X86_FEATURE_FSGSBASE to decide whether to use RDGSBASE/WRGSBASE instructions
or the slower RDMSR/SWAPGS sequence for saving/restoring GSBASE.
On boot CPU, ALTERNATIVE patching happens after enabling FSGSBASE in CR4.
When the feature is available, the code is permanently patched to use
RDGSBASE/WRGSBASE, which require CR4.FSGSBASE=1 to execute without triggering
== Boot Sequence ==
Boot CPU (with CR pinning enabled):
trap_init()
cpu_init() <- Uses unpatched code (RDMSR/SWAPGS)
x2apic_setup()
...
arch_cpu_finalize_init()
identify_boot_cpu()
identify_cpu()
cr4_set_bits(X86_CR4_FSGSBASE) # Enables the feature
# This becomes part of cr4_pinned_bits
...
alternative_instructions() <- Patches code to use RDGSBASE/WRGSBASE
Secondary CPUs (with CR pinning enabled):
start_secondary()
cr4_init() <- Code already patched, CR4.FSGSBASE=1
set implicitly via cr4_pinned_bits
cpu_init() <- exceptions work because FSGSBASE is
already enabled
Secondary CPU (with CR pinning disabled):
start_secondary()
cr4_init() <- Code already patched, CR4.FSGSBASE=0
cpu_init()
x2apic_setup()
rdmsrq(MSR_IA32_APICBASE) <- Triggers #VC in SNP guests
exc_vmm_communication()
paranoid_entry() <- Uses RDGSBASE with CR4.FSGSBASE=0
(patched code)
...
ap_starting()
identify_secondary_cpu()
identify_cpu()
cr4_set_bits(X86_CR4_FSGSBASE) <- Enables the feature, which is
too late
== CR Pinning ==
Currently, for secondary CPUs, CR4.FSGSBASE is set implicitly through
CR-pinning: the boot CPU sets it during identify_cpu(), it becomes part of
cr4_pinned_bits, and cr4_init() applies those pinned bits to secondary CPUs.
This works but creates an undocumented dependency between cr4_init() and the
pinning mechanism.
== Problem ==
Secondary CPUs boot after alternatives have been applied globally. They
execute already-patched paranoid_entry() code that uses RDGSBASE/WRGSBASE
instructions, which require CR4.FSGSBASE=1. Upcoming changes to CR pinning
behavior will break the implicit dependency, causing secondary CPUs to
generate #UD.
This issue manifests itself on AMD SEV-SNP guests, where the rdmsrq() in
x2apic_setup() triggers a #VC exception early during cpu_init(). The #VC
handler (exc_vmm_communication()) executes the patched paranoid_entry() path.
Without CR4.FSGSBASE enabled, RDGSBASE instructions trigger #UD.
== Fix ==
Enable FSGSBASE explicitly in cpu_init_exception_handling() before loading
exception handlers. This makes the dependency explicit and ensures both
boot and secondary CPUs have FSGSBASE enabled before paranoid_entry()
executes.
Fixes: c82965f9e5 ("x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit")
Reported-by: Borislav Petkov <bp@alien8.de>
Suggested-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Cc: <stable@kernel.org>
Link: https://patch.msgid.link/20260318075654.1792916-2-nikunj@amd.com
(cherry picked from commit 05243d490bb7852a8acca7b5b5658019c7797a52)
Assisted-by: Patchpal
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-210859
commit bcbdaa1086c25a8a5d48e04e1b82fdfb0682b681
Author: Fushuai Wang <wangfushuai@baidu.com>
Date: Wed May 20 11:21:19 2026 +0800
cpufreq: intel_pstate: Sync policy->cur during CPU offline
When a CPU goes offline with HWP disabled, intel_pstate_set_min_pstate()
sets the MSR_IA32_PERF_CTL to minimum frequency to prevent SMT siblings
from being restricted. However, the policy->cur value was not updated,
leaving it at the previous value.
When the CPU comes back online, governor->limits() checks if target_freq
equals policy->cur and skips the frequency adjustment if they match. Since
policy->cur still holds the previous value, the governor does not call
cpufreq_driver->target to update MSR_IA32_PERF_CTL.
Fix this by synchronizing policy->cur with the hardware state when setting
minimum pstate during CPU offline.
Fixes: bb18008f80 ("intel_pstate: Set core to min P state during core offline")
Cc: stable@vger.kernel.org # 3.15+
Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
[ rjw: Subject refinement ]
Link: https://patch.msgid.link/20260520032119.30615-1-fushuai.wang@linux.dev
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit bcbdaa1086c25a8a5d48e04e1b82fdfb0682b681)
Assisted-by: Patchpal
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-208745
commit d20457b46eca76b9bb716dd31af591cad21607b5
Author: Muralidhara M K <muralidhara.mk@amd.com>
Date: Fri Jun 12 09:56:08 2026 +0530
platform/x86/amd/hsmp: Clamp ioctl/send_message indices (Spectre v1)
Although validate_message() checks msg_id, a mispredicted branch can
still allow speculative indexing into hsmp_msg_desc_table[]. Clamp
msg.msg_id with array_index_nospec() at entry to hsmp_ioctl_msg() so
downstream dereferences (including via is_get_msg() and
hsmp_send_message()) see a bounded index.
Similarly, hsmp_send_message() bounds-checks msg->sock_ind before
indexing hsmp_pdev.sock[], but a mispredicted branch can still
speculatively use the raw index (Spectre v1, CVE-2017-5753). Apply
array_index_nospec() after the check so every caller that reaches
hsmp_pdev.sock[] through this helper sees a clamped socket
index—including hsmp_ioctl_msg() and any other path that hands a
user-derived struct hsmp_message to hsmp_send_message().
Reviewed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260612042610.1629037-7-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-193546
commit bfc7d93bc5e12288e5dc6bb54260f68cdf5a5c47
Author: Sumeet Pawnikar <sumeet4linux@gmail.com>
Date: Fri May 15 23:56:16 2026 +0530
powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked()
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 <sumeet4linux@gmail.com>
Link: https://patch.msgid.link/20260515182616.227707-1-sumeet4linux@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-185572
commit d51de21b4c3a34a2cc592319df63864e14b18b29
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date: Mon Mar 9 10:38:18 2026 +0200
intel_idle: Add Panther Lake C-states table
Panther Lake supports the following requestable C-states: C1, C1E, C6S,
C10.
The parameters of these C-states should be consistent across all
systems based on Panther Lake, so add a custom C-states table for it
that will override C-state parameters supplied by platform firmware
that may vary from one platform to another and may not represent the
most optimum choice.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
[ rjw: Changelog expansion ]
Link: https://patch.msgid.link/20260309083818.79588-1-dedekind1@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-184884
commit 1b25f03f3daf7c26c37050a7b2b5858ad5f99cfc
Author: Zhang Rui <rui.zhang@intel.com>
Date: Thu Mar 19 13:52:56 2026 +0800
tools/power/x86/intel-speed-select: Fix output when running on unsupported CLX platforms
When running intel-speed-select on unsupported CLX platforms, it prints
intel-speed-select: Invalid CPU model (85)
: Success
Because this is not a system error and errno is not set.
Replace err() with exit().
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-184884
commit 3e244dd513e26728577f1e4deca6fdf749b6f244
Author: Zhang Rui <rui.zhang@intel.com>
Date: Thu Mar 19 13:52:54 2026 +0800
tools/power/x86/intel-speed-select: Fix some program return value
When running the "intel-speed-select -h" command, it returns
1. 0 when using a version that is API incompatible.
2. 1 when using a version that is API compatible.
And this is confusing.
Fix the program to return 0 for "-h" parameter, and return 1 whenever
"Incompatible API versions" is detected.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-184884
commit df4a83543117c7fc27077fd7f4ffe870556b257b
Author: Zhang Rui <rui.zhang@intel.com>
Date: Mon Jan 26 08:27:01 2026 +0800
tools/power/x86/intel-speed-select: Fix cpu extended family ID decoding
When decode and use CPU extended family ID in intel-speed-select, there
are several potential issues,
1. Mask with 0x0f to get CPU extended family ID is bogus because
CPU extended family ID takes 8 bits (bit 27:20).
2. Use CPU extended family ID fields without checking CPU family ID is
risky. Because Intel SDM says, "The Extended Family ID needs to be
examined only when the Family ID is 0FH."
3. Saving cpu family ID and cpu extended family ID separately doesn't
align with Linux kernel. And it may bring extra complexity when
making family specific changes in the future.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-182292
commit ea324444ece9f301b5c4ff71b258cc68990c4d61
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date: Mon Mar 16 16:12:00 2026 +0100
x86/mce: Restore MCA polling interval halving
RongQing reported that the MCA polling interval doesn't halve when an
error gets logged. It was traced down to the commit in Fixes:, because:
mce_timer_fn()
|-> mce_poll_banks()
|-> machine_check_poll()
|-> mce_log()
which will queue the work and return.
Now, back in mce_timer_fn():
/*
* Alert userspace if needed. If we logged an MCE, reduce the polling
* interval, otherwise increase the polling interval.
*/
if (mce_notify_irq())
<--- here we haven't ran the notifier chain yet so mce_need_notify is
not set yet so this won't hit and we won't halve the interval iv.
Now the notifier chain runs. mce_early_notifier() sets the bit, does
mce_notify_irq(), that clears the bit and then the notifier chain
a little later logs the error.
So this is a silly timing issue.
But, that's all unnecessary.
All it needs to happen here is, the "should we notify of a logged MCE"
mce_notify_irq() asks, should be simply a question to the mce gen pool:
"Are you empty?"
And that then turns into a simple yes or no answer and it all
JustWorks(tm).
So do that and also distribute the functionality where it belongs:
- Print that MCE events have been logged in mce_log()
- Trigger the mcelog tool specific work in the first notifier
As a result, mce_notify_irq() can go now.
Fixes: 011d826111 ("RAS: Add a Corrected Errors Collector")
Reported-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Tested-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Link: https://lore.kernel.org/r/20260112082747.2842-1-lirongqing@baidu.com
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-182358
commit 14473e8c4e97d51eff9b2f384ae696f7a32f182b
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date: Thu Apr 30 08:11:03 2026 -0700
platform/x86/intel/tpmi/plr: Prevent fault during unbind
This driver faults when intel vsec driver is unbound from PCI driver
interface. For example:
echo 0000:00:03.1 > /sys/bus/pci/drivers/intel_vsec/unbind
This is caused by accessing plr->dbgfs_dir after vsec_tpmi driver is
removed. Here vsec_tpmi driver is the parent. On unbind, the parent
device remove callback is called first which here will remove debugfs
interface. Hence plr->dbgfs_dir is no longer valid.
Register notifier for TPMI_CORE_EXIT and make this pointer to NULL,
so that debugfs_remove_recursive() is not called with bad plr->dbgfs_dir
pointer.
After notifier is returned the vsec_tpmi driver will call remove debugfs
by calling debugfs_remove_recursive().
Fixes: 811f67c516 ("platform/x86/intel/tpmi: Add new auxiliary driver for performance limits")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Stable@vger.kernel.org
Link: https://patch.msgid.link/20260430151103.1549733-4-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-177639
commit 936cae9254e55a39aeaa0c156a764d22f319338b
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Jan 7 18:02:26 2026 +0200
mei: late_bind: fix struct intel_lb_component_ops kernel-doc
Fix kernel-doc warnings on struct intel_lb_component_ops:
Warning: include/drm/intel/intel_lb_mei_interface.h:55 Incorrect use of
kernel-doc format: * push_payload - Sends a payload to the
authentication firmware
And a bunch more. There isn't really support for documenting function
pointer struct members in kernel-doc, but at least reference the member
properly.
Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver")
Cc: Alexander Usyskin <alexander.usyskin@intel.com>
Reviewed-by: Nitin Gote <nitin.r.gote@intel.com>
Link: https://patch.msgid.link/20260107160226.2381388-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-177639
commit 06d5a7afe1d0b47102936d8fba568572c2b4b941
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date: Sun Jan 11 16:51:25 2026 +0200
mei: trace: treat reg parameter as string
The commit
afd2627f727b ("tracing: Check "%s" dereference via the field and not the TP_printk format")
forbids to emit event with a plain char* without a wrapper.
The reg parameter always passed as static string and wrapper
is not strictly required, contrary to dev parameter.
Use the string wrapper anyway to check sanity of the reg parameters,
store it value independently and prevent internal kernel data leaks.
Since some code refactoring has taken place, explicit backporting may
be needed for kernels older than 6.10.
Cc: stable@vger.kernel.org # v6.11+
Fixes: a0a927d06d ("mei: me: add io register tracing")
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Link: https://patch.msgid.link/20260111145125.1754912-1-alexander.usyskin@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-177639
commit a6dab2f61d23c1eb32f1d08fa7b4919a2478950b
Author: Ma Ke <make24@iscas.ac.cn>
Date: Tue Nov 4 10:01:33 2025 +0800
mei: Fix error handling in mei_register
mei_register() fails to release the device reference in error paths
after device_initialize(). During normal device registration, the
reference is properly handled through mei_deregister() which calls
device_destroy(). However, in error handling paths (such as cdev_alloc
failure, cdev_add failure, etc.), missing put_device() calls cause
reference count leaks, preventing the device's release function
(mei_device_release) from being called and resulting in memory leaks
of mei_device.
Found by code review.
Cc: stable <stable@kernel.org>
Fixes: 7704e6be4ed2 ("mei: hook mei_device on class device")
Signed-off-by: Ma Ke <make24@iscas.ac.cn>
Acked-by: Alexander Usyskin <alexander.usyskin@intel.com>
Link: https://patch.msgid.link/20251104020133.5017-1-make24@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-177639
commit 98718e80af0bb1cd80f4bfe565dd60c57debad51
Author: Nathan Chancellor <nathan@kernel.org>
Date: Sat Sep 20 16:17:50 2025 -0700
mei: late_bind: Fix -Wincompatible-function-pointer-types-strict
When building with -Wincompatible-function-pointer-types-strict, a
warning designed to catch kernel control flow integrity (kCFI) issues at
build time, there is an instance in the new mei late binding code
originating from the type parameter of mei_lb_push_payload():
drivers/misc/mei/mei_lb.c:211:18: error: incompatible function pointer types initializing 'int (*)(struct device *, u32, u32, const void *, size_t)' (aka 'int (*)(struct device *, unsigned int, unsigned int, const void *, unsigned long)') with an expression of type 'int (struct device *, enum intel_lb_type, u32, const void *, size_t)' (aka 'int (struct device *, enum intel_lb_type, unsigned int, const void *, unsigned long)') [-Werror,-Wincompatible-function-pointer-types-strict]
211 | .push_payload = mei_lb_push_payload,
| ^~~~~~~~~~~~~~~~~~~
While 'unsigned int' and 'enum intel_lb_type' are ABI compatible, hence
no regular warning from -Wincompatible-function-pointer-types, the
mismatch will trigger a kCFI violation when mei_lb_push_payload() is
called indirectly.
Update the type parameter of mei_lb_push_payload() to be 'u32' to match
the prototype in 'struct intel_lb_component_ops', clearing up the
warning and kCFI violation.
Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20250920-drm-xe-fix-wifpts-v1-1-c89b5357c7ba@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-177639
Conflicts: drm parts are already in RHEL
commit 741eeabb7c78c555c4c8e39df91b2b8e8d6f5ec6
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date: Fri Sep 5 21:19:46 2025 +0530
mei: late_bind: add late binding component driver
Introduce a new MEI client driver to support Late Binding firmware
upload/update for Intel discrete graphics platforms.
Late Binding is a runtime firmware upload/update mechanism that allows
payloads, such as fan control and voltage regulator, to be securely
delivered and applied without requiring SPI flash updates or
system reboots. This driver enables the Xe graphics driver and other
user-space tools to push such firmware blobs to the authentication
firmware via the MEI interface.
The driver handles authentication, versioning, and communication
with the authentication firmware, which in turn coordinates with
the PUnit/PCODE to apply the payload.
This is a foundational component for enabling dynamic, secure,
and re-entrant configuration updates on platforms like Battlemage.
Cc: Badal Nilawar <badal.nilawar@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250905154953.3974335-3-badal.nilawar@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-177639
commit 2cedb296988c384e1555d74fb55e3b7b9fb268ae
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date: Thu Sep 18 16:04:31 2025 +0300
mei: me: trigger link reset if hw ready is unexpected
Driver can receive HW not ready interrupt unexpectedly.
E.g. for cards that go donwn to D3cold.
Trigger link reset in this case to synchronize driver and
firmware state.
No need to do that sync if driver is going down or interrupt is
received before driver started initial link reset sequence.
Introduce UNINITIALIZED device state to allow interrupt handler
to ignore interrupts before first init.
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250918130435.3327400-2-alexander.usyskin@intel.com
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-177639
commit 7704e6be4ed2835832c445807cdcb2d56d8a8430
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date: Tue Aug 26 15:56:17 2025 +0300
mei: hook mei_device on class device
mei_device lifetime was managed by devm procedure of parent device.
But such memory is freed on device_del.
Mei_device object is used by client object that may be alive after
parent device is removed.
It may lead to use-after-free if discrete graphics driver unloads
mei_gsc auxiliary device while user-space holds open handle to mei
character device.
Connect mei_device structure lifteme to mei class device lifetime
by adding mei_device free to class device remove callback.
Move exising parent device pointer to separate field in mei_device
to avoid misuse.
Allocate character device dynamically and allow to control its own
lifetime as it may outlive mei_device structure while character
device closes after parent device is removed from the system.
Leave power management on parent device as we overwrite pci runtime
pm procedure and user-space is expecting it there.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14201
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Link: https://lore.kernel.org/r/20250826125617.1166546-1-alexander.usyskin@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176441
commit f6bc712877f24dc89bdfd7bdbf1a32f3b9960b34
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Wed Jan 28 10:55:22 2026 +0100
platform/x86: int0002: Remove IRQF_ONESHOT from request_irq()
Passing IRQF_ONESHOT ensures that the interrupt source is masked until the
secondary (threaded) handler is done. If only a primary handler is used
then the flag makes no sense because the interrupt cannot fire (again)
while its handler is running.
The flag also prevents force-threading of the primary handler and the
irq-core will warn about this.
The flag was added to match the flag on the shared handler which uses a
threaded handler and therefore IRQF_ONESHOT. This is no longer needed
because devm_request_irq() now passes IRQF_COND_ONESHOT for this case.
Revert adding IRQF_ONESHOT to irqflags.
Fixes: 8f812373d1 ("platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()")
Reported-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://patch.msgid.link/20260128095540.863589-3-bigeasy@linutronix.de
Closes: https://lore.kernel.org/all/555f1c56-0f74-41bf-8bd2-6217e0aab0c6@intel.com
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176441
commit 25e9e322d2ab5c03602eff4fbf4f7c40019d8de2
Author: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Date: Wed Dec 24 08:50:53 2025 +0530
platform/x86: intel_telemetry: Fix swapped arrays in PSS output
The LTR blocking statistics and wakeup event counters are incorrectly
cross-referenced during debugfs output rendering. The code populates
pss_ltr_blkd[] with LTR blocking data and pss_s0ix_wakeup[] with wakeup
data, but the display loops reference the wrong arrays.
This causes the "LTR Blocking Status" section to print wakeup events
and the "Wakes Status" section to print LTR blockers, misleading power
management analysis and S0ix residency debugging.
Fix by aligning array usage with the intended output section labels.
Fixes: 87bee29099 ("platform:x86: Add Intel Telemetry Debugfs interfaces")
Cc: stable@vger.kernel.org
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Link: https://patch.msgid.link/20251224032053.3915900-1-kaushlendra.kumar@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176441
Upstream Status: git@gitlab.com:cki-project/kernel-ark.git
commit 981c3f3f78c3cbb955a94468b90dcfa1c43d6149
Author: Fedora Kernel Team <kernel-team@fedoraproject.org>
Date: Fri Dec 5 13:36:04 2025 +0000
[redhat] New configs in drivers/platform
Hi,
As part of the ongoing rebase effort, the following configuration
options need to be reviewed.
As a reminder, the ARK configuration flow involves moving unreviewed
configuration options from the pending directory to the ark directory.
In the diff below, options are removed from the pending directory and
added to the ark hierarchy. The final options that need to be ACKed
are the files that are being added to the ark hierarchy.
If the value for a file that is added should be changed, please reply
with a better option.
~~~
Symbol: INTEL_EHL_PSE_IO [=n]
Type : tristate
Defined at drivers/platform/x86/intel/Kconfig:44
Prompt: Intel Elkhart Lake PSE I/O driver
Depends on: X86_PLATFORM_DEVICES [=y] && PCI [=y]
Location:
-> Device Drivers
-> X86 Platform Specific Device Drivers (X86_PLATFORM_DEVICES [=y])
-> Intel Elkhart Lake PSE I/O driver (INTEL_EHL_PSE_IO [=n])
Selects: AUXILIARY_BUS [=y]
~~~
Commit: a0c83150eea5 (platform/x86/intel: Introduce Intel Elkhart Lake PSE I/O)
---
Signed-off-by: Fedora Kernel Team <kernel-team@fedoraproject.org>
Signed-off-by: Steve Best <sbest@redhat.com>
-# CONFIG_INTEL_EHL_PSE_IO is not set
JIRA: https://issues.redhat.com/browse/RHEL-176441
commit a0c83150eea5807dbedf786f55cd49b14af118a8
Author: Raag Jadav <raag.jadav@intel.com>
Date: Wed Nov 12 09:10:10 2025 +0530
platform/x86/intel: Introduce Intel Elkhart Lake PSE I/O
Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI
devices that expose two different capabilities of GPIO and Timed I/O
as a single PCI function through shared MMIO with below layout.
GPIO: 0x0000 - 0x1000
TIO: 0x1000 - 0x2000
This driver enumerates the PCI parent device and creates auxiliary child
devices for these capabilities. The actual functionalities are provided
by their respective auxiliary drivers.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20251112034040.457801-2-raag.jadav@intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176387
commit 0254329897495c42646144376230add710078937
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date: Sat Oct 11 14:38:37 2025 +0800
platform/x86/amd: hfi: Remove redundant assignment to .owner
The coccicheck tool reports the following warning for this driver:
./hfi.c:509:3-8: No need to set .owner here. The core will do it.
The manual assignment of .owner = THIS_MODULE; in the platform_driver
struct is redundant. The platform_driver_register() function, which is
called to register the driver, is a macro that automatically sets the
driver's owner to THIS_MODULE.
The driver core handles this assignment internally, making the explicit
initialization in the struct definition unnecessary. Remove the
unnecessary line.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20251011063837.2318535-3-visitorckw@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-176387
commit 32647324c77012b7aed7ef48752909510d3c7ec7
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date: Sat Oct 11 14:38:36 2025 +0800
platform/x86/amd: hfi: Remove unused cpumask from cpuinfo struct
The cpus field within the struct amd_hfi_cpuinfo was allocated and set
in the amd_hfi_online() CPU hotplug callback, and subsequently freed in
the amd_hfi_offline() callback.
However, after being initialized, this cpumask was never read or used
for any purpose within the driver. It represents dead code that serves
no functional role.
This change has no impact on the driver's functionality as the removed
code was entirely superfluous.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20251011063837.2318535-2-visitorckw@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-130025
commit c7d54dafa042cf379859dba265fe5afef6fa8770
Author: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Date: Wed Feb 11 14:34:01 2026 -0800
powercap: intel_rapl_tpmi: Remove FW_BUG from invalid version check
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 <rui.zhang@intel.com>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260211223401.1575776-1-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-130025
commit 525e0064f3d81764277036036932e873608a47af
Author: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Date: Mon Feb 9 15:43:10 2026 -0800
powercap: intel_rapl: Expose all package CPUs in PMU cpumask
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 <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Furquim Ulisses <ulisses.furquim@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260209234310.1440722-3-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-130025
commit 7537bae8b6eb635583e0e6260f61d13ddbd52087
Author: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Date: Mon Feb 9 15:43:09 2026 -0800
powercap: intel_rapl: Remove incorrect CPU check in PMU context
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 <sathyanarayanan.kuppuswamy@linux.intel.com>
Tested-by: Furquim Ulisses <ulisses.furquim@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260209234310.1440722-2-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-130025
commit 07e5e811f86dcd6f595c3bbd71cde294e8545889
Author: Sumeet Pawnikar <sumeet4linux@gmail.com>
Date: Sun Jan 11 19:42:36 2026 +0530
powercap: Replace sprintf() with sysfs_emit() in sysfs show functions
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 <sumeet4linux@gmail.com>
Link: https://patch.msgid.link/20260111141237.12340-1-sumeet4linux@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-130025
commit efc4c35b741af973de90f6826bf35d3b3ac36bf1
Author: Sumeet Pawnikar <sumeet4linux@gmail.com>
Date: Sun Dec 7 20:45:48 2025 +0530
powercap: fix sscanf() error return value handling
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 <sumeet4linux@gmail.com>
[ rjw: Subject and changelog edits ]
Link: https://patch.msgid.link/20251207151549.202452-1-sumeet4linux@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-130025
commit 7bda1910c4bccd4b8d4726620bb3d6bbfb62286e
Author: Sumeet Pawnikar <sumeet4linux@gmail.com>
Date: Sat Dec 6 00:32:16 2025 +0530
powercap: fix race condition in register_control_type()
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 <sumeet4linux@gmail.com>
[ rjw: Subject adjustment, empty line added ]
Link: https://patch.msgid.link/20251205190216.5032-1-sumeet4linux@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-130025
commit 748d6ba43afde7e9ac27443233203995cc15d235
Author: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Date: Thu Nov 20 16:05:39 2025 -0800
powercap: intel_rapl: Enable MSR-based RAPL PMU support
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 <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Changelog edits ]
Link: https://patch.msgid.link/20251121000539.386069-3-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-130025
commit 1d6c915819f5b805c35487b6ce5923e31a28266b
Author: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Date: Thu Nov 20 16:05:38 2025 -0800
powercap: intel_rapl: Prepare read_raw() interface for atomic-context callers
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 <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/20251121000539.386069-2-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Steve Best <sbest@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-100951
commit bee9f4178b4a3fec70414c82ddc4bceff182f2ba
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date: Sat Mar 7 11:33:14 2026 -0500
x86/mce, EDAC/mce_amd: Reorder SMCA bank type enums
Originally, the SMCA bank type enums were ordered based on processor
documentation. However, the ordering became inconsistent after new bank
types were added over time.
Sort the bank type enums alphanumerically in most places. Sort the
"enum to HWID/McaType" mapping by HWID/McaType. Drop redundant code
comments.
No functional changes.
[ bp: Sort them alphanumerically. ]
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260307163316.345923-2-yazen.ghannam@amd.com
Signed-off-by: Steve Best <sbest@redhat.com>
Steve Best