kernel/git/stable/linux.git/arch/powerpc, branch linux-rolling-lts

integrity: Eliminate weak definition of arch_get_secureboot()

2026-09-14T11:36:18+00:00

[ Upstream commit 7caedbb5ade345df0eec0bf01035c780919a9f56 ] security/integrity/secure_boot.c contains a single __weak function, which breaks recordmcount when building with clang: $ make -skj"$(nproc)" ARCH=powerpc LLVM=1 ppc64_defconfig security/integrity/secure_boot.o Cannot find symbol for section 2: .text. security/integrity/secure_boot.o: failed Introduce a Kconfig symbol, CONFIG_HAVE_ARCH_GET_SECUREBOOT, to indicate that an architecture provides a definition of arch_get_secureboot(). Provide a static inline stub when this symbol is not defined to achieve the same effect as the __weak function, allowing secure_boot.c to be removed altogether. Move the s390 definition of arch_get_secureboot() out of the CONFIG_KEXEC_FILE block to ensure it is always available, as it does not actually depend on KEXEC_FILE. Reported-by: Arnd Bergmann Fixes: 31a6a07eefeb ("integrity: Make arch_ima_get_secureboot integrity-wide") Signed-off-by: Nathan Chancellor Acked-by: Arnd Bergmann Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin

syscore: Pass context data to callbacks

2026-09-14T11:36:10+00:00

[ Upstream commit a97fbc3ee3e2a536fafaff04f21f45472db71769 ] Several drivers can benefit from registering per-instance data along with the syscore operations. To achieve this, move the modifiable fields out of the syscore_ops structure and into a separate struct syscore that can be registered with the framework. Add a void * driver data field for drivers to store contextual data that will be passed to the syscore ops. Acked-by: Rafael J. Wysocki (Intel) Signed-off-by: Thierry Reding Stable-dep-of: cee0d90bceae ("Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition") Signed-off-by: Sasha Levin

integrity: Make arch_ima_get_secureboot integrity-wide

2026-09-14T11:35:50+00:00

[ Upstream commit 31a6a07eefeb4c84bd6730fbe9e95fd9221712cf ] EVM and other LSMs need the ability to query the secure boot status of the system, without directly calling the IMA arch_ima_get_secureboot function. Refactor the secure boot status check into a general function named arch_get_secureboot. Reported-and-suggested-by: Mimi Zohar Suggested-by: Roberto Sassu Signed-off-by: Coiby Xu Acked-by: Ard Biesheuvel Signed-off-by: Mimi Zohar Stable-dep-of: 3f7c9f9c36b4 ("s390/irqflags: Add out-of-line definitions of arch_local_irq_*() for KMSAN") Signed-off-by: Sasha Levin

powerpc/configs: enable CONFIG_RAS to fix EDAC support

2026-09-14T11:35:49+00:00

[ Upstream commit 3921cfc2e8155a767235801be88cbd0e4c73508d ] Before commit e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") EDAC_MM_EDAC selected RAS, after that commit, EDAC depends on RAS, but nobody enables it. Enable it in the config again. Fixes: e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") Signed-off-by: Michael Walle Acked-by: Borislav Petkov (AMD) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260730105546.3658570-1-mwalle@kernel.org Signed-off-by: Sasha Levin

powerpc/irq: Fix missing r2 clobber in PCREL inline assembly

2026-09-14T11:35:31+00:00

[ Upstream commit 00be69070d91d2be978e752bb117a0a4db0e1281 ] In CONFIG_PPC_KERNEL_PCREL mode, r2 is no longer reserved for the TOC pointer and is available as a caller-saved register [0]. Both call_do_irq() and call_do_softirq() use inline assembly to call functions with stack switching, but fail to list r2 in their clobber lists. This causes the compiler to assume r2 is preserved across these calls, leading to register corruption when the called functions (__do_irq and __do_softirq) clobber r2. As a result of this kernel crash during interrupt handling is seen and the kernel fails to boot: BUG: Unable to handle kernel data access on write at 0xc000000404697638 Faulting instruction address: 0xc0000000000181ec Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000181ec] __do_IRQ+0x6c/0xc0 With older GCC, the compiler would conservatively allocate callee-saved registers (like r31) for values spanning function calls, accidentally avoiding the bug: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f8 ff e1 fb std r31,-8(r1) f0 ff c1 fb std r30,-16(r1) 2d 03 10 06 pla r31,53297316 ... 3d e8 ff 4b bl c0000000000165ac <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 4d e9 ld r10,40(r13) 40 00 21 38 addi r1,r1,64 2a f9 aa 7f stdx r29,r10,r31 With newer GCC 14, the compiler uses r2 for such values, exposing the missing clobber specification: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f0 ff c1 fb std r30,-16(r1) f8 ff e1 fb std r31,-8(r1) 29 02 10 06 pla r2,36252592 # c0000000022aadc0 <__irq_regs> ... 85 dc ff 4b bl c000000000015ee0 <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 2d e9 ld r9,40(r13) 30 00 21 38 addi r1,r1,48 2a 11 c9 7f stdx r30,r9,r2 Fix this by adding r2 to the clobber list for both call_do_irq() and call_do_softirq() when CONFIG_PPC_KERNEL_PCREL is enabled. [0]: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg313226.html Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL addresing") Signed-off-by: Saket Kumar Bhaskar Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/10fc2cda485cd22e209a31d786bed1984bdf3982.1785732393.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin

powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass

2026-09-14T11:35:31+00:00

[ Upstream commit 5aabc192702defb8950e7c81b05c3f4ca8ee43ec ] smp_muxed_ipi_message_pass() calls smp_ops->cause_ipi() without checking whether it has been set. On platforms using muxed IPI (e.g. powernv/pseries), smp_ops->cause_ipi is initialized to NULL in the static smp_ops and only assigned during the platform smp_probe() handler. If the IPI subsystem fails to initialize -- for example when xive_init_ipis() fails and xive_smp_probe() returns an error -- the probe handler returns early and cause_ipi is never set. Any subsequent IPI send (e.g. arch_smp_send_reschedule()) would dereference the NULL pointer. Add a NULL check to avoid the crash in that situation. Fixes: 23d72bfd8f9f ("powerpc: Consolidate ipi message mux and demux") Signed-off-by: Gou Hao Reviewed-by: jiazhenyuan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-6-gouhao@uniontech.com Signed-off-by: Sasha Levin

powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()

2026-09-14T11:35:18+00:00

[ Upstream commit 4cc4b586007fbbf8edba4f1d0849e9a06b0cf6c3 ] In get_crash_memory_ranges(), if crash_exclude_mem_range() failed after realloc_mem_ranges() has successfully allocated the cmem memory, it just returns an error but leaves cmem pointing to the allocated memory, nor is it freed in the caller update_crash_elfcorehdr(), which cause a memory leak, goto out to free the cmem. Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support") Reviewed-by: Sourabh Jain Signed-off-by: Jinjie Ruan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-2-ruanjinjie@huawei.com Signed-off-by: Sasha Levin

powerpc/44x: Set GPIO chip parent

2026-09-14T11:35:18+00:00

[ Upstream commit b9254d222d0b38cc6f7b73119fad6316f65278be ] The PPC4xx GPIO driver stopped assigning an explicit parent to the gpio_chip when it moved away from of_mm_gpiochip_add_data(). Restore that association from the platform device so OF GPIO lookup can match phandles to the registered gpiochip. Tested on: Cisco MX60W. No more probe deferral. Assisted-by: Codex:GPT-5.5 Fixes: 1044dbaf2a77 ("powerpc/44x: Change GPIO driver to a proper platform driver") Signed-off-by: Rosen Penev Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Linus Walleij Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260517063754.21819-1-rosenp@gmail.com Signed-off-by: Sasha Levin

powerpc: implement get_direction() in cpm2

2026-09-14T11:35:18+00:00

[ Upstream commit ca16219e9babc874349a6ac307d56523871a9137 ] The lack of get_direction() callback in this driver causes GPIOLIB to emit a warning. Implement it. Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()") Signed-off-by: Christophe Leroy (CS GROUP) Reviewed-by: Bartosz Golaszewski Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/c6eb70aa0e1ba6e15f947c827006aa79edace05c.1785318836.git.chleroy@kernel.org Signed-off-by: Sasha Levin

KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode

2026-09-11T09:49:20+00:00

commit 884ea0283f4effac97ee8f451464a7d1be480d7c upstream. On IBM POWER systems, newer processor generations can operate in compatibility modes corresponding to earlier generations. This becomes relevant for nested virtualization, where nested KVM guests may need to run with a specific processor compatibility level. Currently, when running a nested KVM guest (L2) inside a Power11 pSeries logical partition (L1) booted in Power10 compatibility mode, the guest fails to boot while setting 'arch_compat'. This happens because the CPU class is derived from the hardware PVR (via mfspr()), which reflects the physical processor generation (Power11), rather than the effective compatibility mode (Power10). As a result, userspace may request a Power11 arch_compat for the L2 guest. However, the L1 partition, running in Power10 compatibility, has only negotiated support up to Power10 with the Power Hypervisor (L0). When H_GUEST_SET_STATE is invoked with a Power11 Logical PVR, the hypervisor rejects the request, leading to a late guest boot failure: KVM-NESTEDv2: couldn't set guest wide elements [..KVM reg dump..] This situation should be detected earlier and rejected by KVM. Without proper validation, if userspace ignores the error, the guest may continue to boot in Power11 raw mode on a Power10 compatibility host, which should not be allowed. Introduce a validation mechanism that detects unsupported arch_compat values early in the guest initialization path. When an unsupported arch_compat is requested (e.g., Power11 on a Power10 compatibility mode host), kvmppc_set_arch_compat() uses cpu_has_feature(CPU_FTR_P11_PVR) to detect the mismatch and sets arch_compat to PVR_ARCH_INVALID (0xffffffff). This sentinel value is architecturally safe: PAPR specifies that valid logical PVR values must have 0x0f as the first byte, ensuring 0xffffffff lies permanently outside the specification-defined range. Setting this value triggers kvmppc_sanity_check() to mark the vCPU as invalid by setting vcpu->arch.sane to false. On the next vCPU run, kvmppc_vcpu_run_hv() checks this flag and returns -EINVAL, preventing the guest from running with an invalid processor compatibility configuration. With this, when a Power11 arch_compat is requested on a Power10 compatibility mode host, the guest fails early during boot with: error: kvm run failed Invalid argument This provides a much clearer failure mode compared to the previous behavior where the guest could boot in Power11 raw mode (if userspace ignored the error) or fail late during H_GUEST_SET_STATE. Suggested-by: Vaibhav Jain Reviewed-by: Vaibhav Jain Tested-by: Anushree Mathur Acked-by: Gautam Menghani Cc: stable@vger.kernel.org # v6.13+ Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260714175432.86388-1-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman