summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
12 daysKVM: PPC: e500: Fix build error due to using kmalloc_obj() with wrong typeSean Christopherson
Fix a build error in kvmppc_e500_tlb_init() that was introduced by the conversion to use kzalloc_objs(), as KVM confusingly uses the size of the structure that is one and only field in tlbe_priv: arch/powerpc/kvm/e500_mmu.c:923:33: error: assignment to 'struct tlbe_priv *' from incompatible pointer type 'struct tlbe_ref *' [-Wincompatible-pointer-types] 923 | vcpu_e500->gtlb_priv[0] = kzalloc_objs(struct tlbe_ref, | ^ KVM has been flawed since commit 0164c0f0c404 ("KVM: PPC: e500: clear up confusion between host and guest entries"), but the issue went unnoticed until kmalloc_obj() came along and enforced types, as "struct tlbe_priv" was just a wrapper of "struct tlbe_ref" (why on earth the two ever existed separately...). Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types") Cc: Kees Cook <kees@kernel.org> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Link: https://patch.msgid.link/20260303190339.974325-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysMerge tag 'kvmarm-fixes-7.0-3' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.0, take #3 - Correctly handle deeactivation of out-of-LRs interrupts by starting the EOIcount deactivation walk *after* the last irq that made it into an LR. This avoids deactivating irqs that are in the LRs and that the vcpu hasn't deactivated yet. - Avoid calling into the stubs to probe for ICH_VTR_EL2.TDS when pKVM is already enabled -- not only thhis isn't possible (pKVM will reject the call), but it is also useless: this can only happen for a CPU that has already booted once, and the capability will not change.
12 daysMerge tag 'kvm-x86-generic-7.0-rc3' of https://github.com/kvm-x86/linux into ↵Paolo Bonzini
HEAD KVM generic changes for 7.0 - Remove a subtle pseudo-overlay of kvm_stats_desc, which, aside from being unnecessary and confusing, triggered compiler warnings due to -Wflex-array-member-not-at-end. - Document that vcpu->mutex is take outside of kvm->slots_lock and kvm->slots_arch_lock, which is intentional and desirable despite being rather unintuitive.
12 daysMerge tag 'kvm-riscv-fixes-7.0-1' of https://github.com/kvm-riscv/linux into ↵Paolo Bonzini
HEAD KVM/riscv fixes for 7.0, take #1 - Prevent speculative out-of-bounds access using array_index_nospec() in APLIC interrupt handling, ONE_REG regiser access, AIA CSR access, float register access, and PMU counter access - Fix potential use-after-free issues in kvm_riscv_gstage_get_leaf(), kvm_riscv_aia_aplic_has_attr(), and kvm_riscv_aia_imsic_has_attr() - Fix potential null pointer dereference in kvm_riscv_vcpu_aia_rmw_topei() - Fix off-by-one array access in SBI PMU - Skip THP support check during dirty logging - Fix error code returned for Smstateen and Ssaia ONE_REG interface - Check host Ssaia extension when creating AIA irqchip
12 daysx86/hyperv: Use __naked attribute to fix stackless C functionArd Biesheuvel
hv_crash_c_entry() is a C function that is entered without a stack, and this is only allowed for functions that have the __naked attribute, which informs the compiler that it must not emit the usual prologue and epilogue or emit any other kind of instrumentation that relies on a stack frame. So split up the function, and set the __naked attribute on the initial part that sets up the stack, GDT, IDT and other pieces that are needed for ordinary C execution. Given that function calls are not permitted either, use the existing long return coded in an asm() block to call the second part of the function, which is an ordinary function that is permitted to call other functions as usual. Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> # asm parts, not hv parts Reviewed-by: Mukesh Rathor <mrathor@linux.microsoft.com> Acked-by: Uros Bizjak <ubizjak@gmail.com> Cc: Wei Liu <wei.liu@kernel.org> Cc: linux-hyperv@vger.kernel.org Fixes: 94212d34618c ("x86/hyperv: Implement hypervisor RAM collection into vmcore") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Wei Liu <wei.liu@kernel.org>
12 daysMerge tag 'powerpc-7.0-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Madhavan Srinivasan: - Correct MSI allocation tracking - Always use 64 bits PTE for powerpc/e500 - Fix inline assembly for clang build on PPC32 - Fixes for clang build issues in powerpc64/ftrace - Fixes for powerpc64/bpf JIT and tailcall support - Cleanup MPC83XX devicetrees - Fix keymile vendor prefix - Fix to use big-endian types for crash variables Thanks to Abhishek Dubey, Christophe Leroy (CS GROUP), Hari Bathini, Heiko Schocher, J. Neuschäfer, Mahesh Salgaonkar, Nam Cao, Nilay Shroff, Rob Herring (Arm), Saket Kumar Bhaskar, Sourabh Jain, Stan Johnson, and Venkat Rao Bagalkote. * tag 'powerpc-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (23 commits) powerpc/pseries: Correct MSI allocation tracking powerpc: dts: mpc83xx: Add unit addresses to /memory powerpc: dts: mpc8315erdb: Add missing #cells properties to SPI bus powerpc: dts: mpc8315erdb: Rename LED nodes to comply with schema powerpc: dts: mpc8315erdb: Use IRQ_TYPE_* macros powerpc: dts: mpc8313erdb: Use IRQ_TYPE_* macros powerpc: 83xx: km83xx: Fix keymile vendor prefix dt-bindings: powerpc: Add Freescale/NXP MPC83xx SoCs powerpc64/bpf: fix kfunc call support powerpc64/bpf: fix handling of BPF stack in exception callback powerpc64/bpf: remove BPF redzone protection in trampoline stack powerpc64/bpf: use consistent tailcall offset in trampoline powerpc64/bpf: fix the address returned by bpf_get_func_ip powerpc64/bpf: do not increment tailcall count when prog is NULL powerpc64/ftrace: workaround clang recording GEP in __patchable_function_entries powerpc64/ftrace: fix OOL stub count with clang powerpc64: make clang cross-build friendly powerpc/crash: adjust the elfcorehdr size powerpc/kexec/core: use big-endian types for crash variables powerpc/prom_init: Fixup missing #size-cells on PowerMac media-bay nodes ...
13 daysx86/apic: Disable x2apic on resume if the kernel expects soShashank Balaji
When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: CPU configuration. Platform runtime firmware restores the pre-sleep configuration or initial boot configuration of each CPU (MSR, MTRR, firmware update, SMBase, and so on). Interrupts must be disabled (for IA-32 processors, disabled by CLI instruction). (and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if "x2apic on" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ] Fixes: 6e1cb38a2aef ("x64, x2apic/intr-remap: add x2apic support, including enabling interrupt-remapping") Co-developed-by: Rahul Bukte <rahul.bukte@sony.com> Signed-off-by: Rahul Bukte <rahul.bukte@sony.com> Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260306-x2apic-fix-v2-1-bee99c12efa3@sony.com
13 daysKVM: arm64: pkvm: Don't reprobe for ICH_VTR_EL2.TDS on CPU hotplugMarc Zyngier
Hotplugging a CPU off and back on fails with pKVM, as we try to probe for ICH_VTR_EL2.TDS. In a non-VHE setup, this is achieved by using an EL2 stub helper. However, the stubs are out of reach once pKVM has deprivileged the kernel. The CPU never boots. Since pKVM doesn't allow late onlining of CPUs, we can detect that protected mode is enforced early on, and return the current state of the capability. Fixes: 2a28810cbb8b2 ("KVM: arm64: GICv3: Detect and work around the lack of ICV_DIR_EL1 trapping") Reported-by: Vincent Donnefort <vdonnefort@google.com> Tested-by: Vincent Donnefort <vdonnefort@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260310085433.3936742-1-maz@kernel.org Cc: stable@vger.kernel.org
14 dayscrypto: arm64/aes-neonbs - Move key expansion off the stackCheng-Yang Chou
aesbs_setkey() and aesbs_cbc_ctr_setkey() allocate struct crypto_aes_ctx on the stack. On arm64, the kernel-mode NEON context is also stored on the stack, causing the combined frame size to exceed 1024 bytes and triggering -Wframe-larger-than= warnings. Allocate struct crypto_aes_ctx on the heap instead and use kfree_sensitive() to ensure the key material is zeroed on free. Use a goto-based cleanup path to ensure kfree_sensitive() is always called. Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Fixes: 4fa617cc6851 ("arm64/fpsimd: Allocate kernel mode FP/SIMD buffers on the stack") Link: https://lore.kernel.org/r/20260306064254.2079274-1-yphbchou0911@gmail.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-03-08Merge tag 'efi-fixes-for-v7.0-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fix from Ard Biesheuvel: "Fix for the x86 EFI workaround keeping boot services code and data regions reserved until after SetVirtualAddressMap() completes: deferred struct page initialization may result in some of this memory being lost permanently" * tag 'efi-fixes-for-v7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: x86/efi: defer freeing of boot services memory
2026-03-07Merge tag 'x86-urgent-2026-03-08' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Fix SEV guest boot failures in certain circumstances, due to very early code relying on a BSS-zeroed variable that isn't actually zeroed yet an may contain non-zero bootup values Move the variable into the .data section go gain even earlier zeroing - Expose & allow the IBPB-on-Entry feature on SNP guests, which was not properly exposed to guests due to initial implementational caution - Fix O= build failure when CONFIG_EFI_SBAT_FILE is using relative file paths - Fix the various SNC (Sub-NUMA Clustering) topology enumeration bugs/artifacts (sched-domain build errors mostly). SNC enumeration data got more complicated with Granite Rapids X (GNR) and Clearwater Forest X (CWF), which exposed these bugs and made their effects more serious - Also use the now sane(r) SNC code to fix resctrl SNC detection bugs - Work around a historic libgcc unwinder bug in the vdso32 sigreturn code (again), which regressed during an overly aggressive recent cleanup of DWARF annotations * tag 'x86-urgent-2026-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/entry/vdso32: Work around libgcc unwinder bug x86/resctrl: Fix SNC detection x86/topo: Fix SNC topology mess x86/topo: Replace x86_has_numa_in_package x86/topo: Add topology_num_nodes_per_package() x86/numa: Store extra copy of numa_nodes_parsed x86/boot: Handle relative CONFIG_EFI_SBAT_FILE file paths x86/sev: Allow IBPB-on-Entry feature for SNP guests x86/boot/sev: Move SEV decompressor variables into the .data section
2026-03-07KVM: arm64: vgic: Pick EOIcount deactivations from AP-list tailMarc Zyngier
Valentine reports that their guests fail to boot correctly, losing interrupts, and indicates that the wrong interrupt gets deactivated. What happens here is that if the maintenance interrupt is slow enough to kick us out of the guest, extra interrupts can be activated from the LRs. We then exit and proceed to handle EOIcount deactivations, picking active interrupts from the AP list. But we start from the top of the list, potentially deactivating interrupts that were in the LRs, while EOIcount only denotes deactivation of interrupts that are not present in an LR. Solve this by tracking the last interrupt that made it in the LRs, and start the EOIcount deactivation walk *after* that interrupt. Since this only makes sense while the vcpu is loaded, stash this in the per-CPU host state. Huge thanks to Valentine for doing all the detective work and providing an initial patch. Fixes: 3cfd59f81e0f3 ("KVM: arm64: GICv3: Handle LR overflow when EOImode==0") Fixes: 281c6c06e2a7b ("KVM: arm64: GICv2: Handle LR overflow when EOImode==0") Reported-by: Valentine Burley <valentine.burley@collabora.com> Tested-by: Valentine Burley <valentine.burley@collabora.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20260307115955.369455-1-valentine.burley@collabora.com Link: https://patch.msgid.link/20260307191151.3781182-1-maz@kernel.org Cc: stable@vger.kernel.org
2026-03-07s390: Revert "s390/irq/idle: Remove psw bits early"Heiko Carstens
This reverts commit d8b5cf9c63143fae54a734c41e3bb55cf3f365c7. Mikhail Zaslonko reported that linux-next doesn't boot anymore [2]. Reason for this is recent change [2] was supposed to slightly optimize the irq entry/exit path by removing some psw bits early in case of an idle exit. This however is incorrect since irqentry_exit() requires the correct old psw state at irq entry. Otherwise the embedded regs_irqs_disabled() will not provide the correct result. With linux-next and HRTIMER_REARM_DEFERRED this leads to the observed boot problems, however the commit is broken in any case. Revert the commit which introduced this. Thanks to Peter Zijlstra for pointing out that this is a bug in the s390 entry code. Fixes: d8b5cf9c6314 ("s390/irq/idle: Remove psw bits early") [1] Reported-by: Mikhail Zaslonko <zaslonko@linux.ibm.com> Reported-by: Peter Zijlstra <peterz@infradead.org> Closes: https://lore.kernel.org/r/af549a19-db99-4b16-8511-bf315177a13e@linux.ibm.com/ [2] Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Mikhail Zaslonko <zaslonko@linux.ibm.com> Tested-by: Mikhail Zaslonko <zaslonko@linux.ibm.com> Acked-by: Vasily Gorbik <gor@linux.ibm.com> Link: https://lore.kernel.org/r/20260306111919.362559-1-hca@linux.ibm.com Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-03-07Merge tag 'parisc-for-7.0-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "While testing Sasha Levin's 'kallsyms: embed source file:line info in kernel stack traces' patch series, which increases the typical kernel image size, I found some issues with the parisc initial kernel mapping which may prevent the kernel to boot. The three small patches here fix this" * tag 'parisc-for-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix initial page table creation for boot parisc: Check kernel mapping earlier at bootup parisc: Increase initial mapping to 64 MB with KALLSYMS
2026-03-07Merge tag 'for-linus-7.0-rc3-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - a cleanup of arch/x86/kernel/head_64.S removing the pre-built page tables for Xen guests - a small comment update - another cleanup for Xen PVH guests mode - fix an issue with Xen PV-devices backed by driver domains * tag 'for-linus-7.0-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/xenbus: better handle backend crash xenbus: add xenbus_device parameter to xenbus_read_driver_state() x86/PVH: Use boot params to pass RSDP address in start_info page x86/xen: update outdated comment xen/acpi-processor: fix _CST detection using undersized evaluation buffer x86/xen: Build identity mapping page tables dynamically for XENPV
2026-03-07powerpc/pseries: Correct MSI allocation trackingNam Cao
The per-device MSI allocation calculation in pseries_irq_domain_alloc() is clearly wrong. It can still happen to work when nr_irqs is 1. Correct it. Fixes: c0215e2d72de ("powerpc/pseries: Fix MSI-X allocation failure when quota is exceeded") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> [maddy: Fixed Nilay's reviewed-by tag] Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260302003948.1452016-1-namcao@linutronix.de
2026-03-07powerpc: dts: mpc83xx: Add unit addresses to /memoryJ. Neuschäfer
This fixes dtschema warnings such as the following: arch/powerpc/boot/dts/mpc8315erdb.dtb: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]} Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303-mpc83xx-cleanup-v2-5-187d3a13effa@posteo.net
2026-03-07powerpc: dts: mpc8315erdb: Add missing #cells properties to SPI busJ. Neuschäfer
These properties are required by the spi-controller binding. Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303-mpc83xx-cleanup-v2-4-187d3a13effa@posteo.net
2026-03-07powerpc: dts: mpc8315erdb: Rename LED nodes to comply with schemaJ. Neuschäfer
The leds-gpio.yaml schema requires that GPIO LED nodes contain "led", and preferably start with "led-" Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303-mpc83xx-cleanup-v2-3-187d3a13effa@posteo.net
2026-03-07powerpc: dts: mpc8315erdb: Use IRQ_TYPE_* macrosJ. Neuschäfer
This increases readability, because "0x8" isn't very descriptive. mpc8315erdb.dtb remains identical after this patch. Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303-mpc83xx-cleanup-v2-2-187d3a13effa@posteo.net
2026-03-07powerpc: dts: mpc8313erdb: Use IRQ_TYPE_* macrosJ. Neuschäfer
This increases readability, because "0x8" isn't very descriptive. mpc8313erdb.dtb remains identical after this patch. Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303-mpc83xx-cleanup-v2-1-187d3a13effa@posteo.net
2026-03-07powerpc: 83xx: km83xx: Fix keymile vendor prefixJ. Neuschäfer
When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor prefix was changed to upper-case "Keymile". The devicetree at arch/powerpc/boot/dts/kmeter1.dts never underwent the same change, suggesting that this was simply a mistake. Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1") Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Reviewed-by: Heiko Schocher <hs@nabladev.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net
2026-03-07powerpc64/bpf: fix kfunc call supportHari Bathini
Commit 61688a82e047 ("powerpc/bpf: enable kfunc call") inadvertently enabled kfunc call support for 32-bit powerpc but that support will not be possible until ABI mismatch between 32-bit powerpc and eBPF is handled in 32-bit powerpc JIT code. Till then, advertise support only for 64-bit powerpc. Also, in powerpc ABI, caller needs to extend the arguments properly based on signedness. The JIT code is responsible for handling this explicitly for kfunc calls as verifier can't handle this for each architecture-specific ABI needs. But this was not taken care of while kfunc call support was enabled for powerpc. Fix it by handling this with bpf_jit_find_kfunc_model() and using zero_extend() & sign_extend() helper functions. Fixes: 61688a82e047 ("powerpc/bpf: enable kfunc call") Cc: stable@vger.kernel.org Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303181031.390073-7-hbathini@linux.ibm.com
2026-03-07powerpc64/bpf: fix handling of BPF stack in exception callbackHari Bathini
Exception callback reuses the stack frame of exception boundary. When exception boundary and exception callback programs have different BPF stack depth, the current stack unwind in exception callback will fail. Adjust the stack frame size of exception callback, in its prologue, if its BPF stack depth is different from that of exception boundary. Reported-by: bot+bpf-ci@kernel.org Closes: https://lore.kernel.org/bpf/2a310e86a59eb4c44c3ac9e5647814469d9c955580c9c0f1b3d9ca4a44717a34@mail.kernel.org/ Fixes: 11d45eee9f42 ("powerpc64/bpf: Additional NVR handling for bpf_throw") Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303181031.390073-6-hbathini@linux.ibm.com
2026-03-07powerpc64/bpf: remove BPF redzone protection in trampoline stackHari Bathini
Since bpf2bpf tailcall support is enabled for 64-bit powerpc with kernel commit 2ed2d8f6fb38 ("powerpc64/bpf: Support tailcalls with subprogs"), 'tailcalls/tailcall_bpf2bpf_hierarchy_fexit' BPF selftest is triggering "corrupted stack end detected inside scheduler" with the config option CONFIG_SCHED_STACK_END_CHECK enabled. While reviewing the stack layout for BPF trampoline, observed that the dummy frame is trying to protect the redzone of BPF program. This is because tail call info and NVRs save area are in redzone at the time of tailcall as the current BPF program stack frame is teared down before the tailcall. But saving this redzone in the dummy frame of trampoline is unnecessary because of the follow reasons: 1) Firstly, trampoline can be attached to BPF entry/main program or subprog. But prologue part of the BPF entry/main program, where the trampoline attachpoint is, is skipped during tailcall. So, protecting the redzone does not arise when the trampoline is not even triggered in this scenario. 2) In case of subprog, the caller's stackframe is already setup and the subprog's stackframe is yet to be setup. So, nothing on the redzone to be protected. Also, using dummy frame in BPF trampoline, wastes critically scarce kernel stack space, especially in tailcall sequence, for marginal benefit in stack unwinding. So, drop setting up the dummy frame. Instead, save return address in bpf trampoline frame and use it as appropriate. Pruning this unnecessary stack usage mitigates the likelihood of stack overflow in scenarios where bpf2bpf tailcalls and fexit programs are mixed. Reported-by: Saket Kumar Bhaskar <skb99@linux.ibm.com> Fixes: 2ed2d8f6fb38 ("powerpc64/bpf: Support tailcalls with subprogs") Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303181031.390073-5-hbathini@linux.ibm.com
2026-03-07powerpc64/bpf: use consistent tailcall offset in trampolineHari Bathini
Ideally, the offset used to load the tail call info field and to find the pass by reference address for tail call field should be the same. But while setting up the tail call info in the trampoline, this was not followed. This can be misleading and can lead to unpredictable results if and when bpf_has_stack_frame() ends up returning true for trampoline frame. Since commit 15513beeb673 ("powerpc64/bpf: Moving tail_call_cnt to bottom of frame") and commit 2ed2d8f6fb38 ("powerpc64/bpf: Support tailcalls with subprogs") ensured tail call field is at the bottom of the stack frame for BPF programs as well as BPF trampoline, avoid relying on bpf_jit_stack_tailcallinfo_offset() and bpf_has_stack_frame() for trampoline frame and always calculate tail call field offset with reference to older frame. Fixes: 2ed2d8f6fb38 ("powerpc64/bpf: Support tailcalls with subprogs") Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303181031.390073-4-hbathini@linux.ibm.com
2026-03-07powerpc64/bpf: fix the address returned by bpf_get_func_ipHari Bathini
bpf_get_func_ip() helper function returns the address of the traced function. It relies on the IP address stored at ctx - 16 by the bpf trampoline. On 64-bit powerpc, this address is recovered from LR accounting for OOL trampoline. But the address stored here was off by 4-bytes. Ensure the address is the actual start of the traced function. Reported-by: Abhishek Dubey <adubey@linux.ibm.com> Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines") Cc: stable@vger.kernel.org Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303181031.390073-3-hbathini@linux.ibm.com
2026-03-07powerpc64/bpf: do not increment tailcall count when prog is NULLHari Bathini
Do not increment tailcall count, if tailcall did not succeed due to missing BPF program. Fixes: ce0761419fae ("powerpc/bpf: Implement support for tail calls") Cc: stable@vger.kernel.org Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260303181031.390073-2-hbathini@linux.ibm.com
2026-03-07powerpc64/ftrace: workaround clang recording GEP in __patchable_function_entriesHari Bathini
Support for -fpatchable-function-entry on ppc64le was added in Clang with [1]. However, when no prefix NOPs are specified - as is the case with CONFIG_PPC_FTRACE_OUT_OF_LINE - the first NOP is emitted at LEP, but Clang records the Global Entry Point (GEP) unlike GCC which does record the Local Entry Point (LEP). Issue [2] has been raised to align Clang's behavior with GCC. As a temporary workaround to ensure ftrace initialization works as expected with Clang, derive the LEP using ppc_function_entry() for kernel symbols and by looking for the below module GEP sequence for module addresses, until [2] is resolved: ld r2, -8(r12) add r2, r2, r12 [1] https://github.com/llvm/llvm-project/pull/151569 [2] https://github.com/llvm/llvm-project/issues/163706 Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260127084926.34497-4-hbathini@linux.ibm.com
2026-03-07powerpc64/ftrace: fix OOL stub count with clangHari Bathini
The total number of out-of-line (OOL) stubs required for function tracing is determined using the following command: $(OBJDUMP) -r -j __patchable_function_entries vmlinux.o While this works correctly with GNU objdump, llvm-objdump does not list the expected relocation records for this section. Fix this by using the -d option and counting R_PPC64_ADDR64 relocation entries. This works as desired with both objdump and llvm-objdump. Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260127084926.34497-3-hbathini@linux.ibm.com
2026-03-07powerpc64: make clang cross-build friendlyHari Bathini
ARCH_USING_PATCHABLE_FUNCTION_ENTRY depends on toolchain support for -fpatchable-function-entry option. The current script that checks for this support only handles GCC. Rename the script and extend it to detect support for -fpatchable-function-entry with Clang as well, allowing clean cross-compilation with Clang toolchains. Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260127084926.34497-2-hbathini@linux.ibm.com
2026-03-06Merge tag 'kbuild-fixes-7.0-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild fixes from Nathan Chancellor: - Split out .modinfo section from ELF_DETAILS macro, as that macro may be used in other areas that expect to discard .modinfo, breaking certain image layouts - Adjust genksyms parser to handle optional attributes in certain declarations, necessary after commit 07919126ecfc ("netfilter: annotate NAT helper hook pointers with __rcu") - Include resolve_btfids in external module build created by scripts/package/install-extmod-build when it may be run on external modules - Avoid removing objtool binary with 'make clean', as it is required for external module builds * tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: Leave objtool binary around with 'make clean' kbuild: install-extmod-build: Package resolve_btfids if necessary genksyms: Fix parsing a declarator with a preceding attribute kbuild: Split .modinfo out from ELF_DETAILS
2026-03-06Merge tag 's390-7.0-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Fix stackleak and xor lib inline asm, constraints and clobbers to prevent miscompilations and incomplete stack poisoning * tag 's390-7.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/stackleak: Fix __stackleak_poison() inline assembly constraint s390/xor: Improve inline assembly constraints s390/xor: Fix xor_xc_2() inline assembly constraints s390/xor: Fix xor_xc_5() inline assembly
2026-03-06Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "The main changes are a fix to the way in which we manage the access flag setting for mappings using the contiguous bit and a fix for a hang on the kexec/hibernation path. Summary: - Fix kexec/hibernation hang due to bogus read-only mappings - Fix sparse warnings in our cmpxchg() implementation - Prevent runtime-const being used in modules, just like x86 - Fix broken elision of access flag modifications for contiguous entries on systems without support for hardware updates - Fix a broken SVE selftest that was testing the wrong instruction" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: selftest/arm64: Fix sve2p1_sigill() to hwcap test arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults arm64: make runtime const not usable by modules arm64: mm: Add PTE_DIRTY back to PAGE_KERNEL* to fix kexec/hibernation arm64: Silence sparse warnings caused by the type casting in (cmp)xchg
2026-03-06Merge tag 'pci-v7.0-fixes-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fixes from Bjorn Helgaas: - Initialize msi_addr_mask for OF-created PCI devices to fix sparc and powerpc probe regressions (Nilay Shroff) - Orphan the Altera PCIe controller driver (Dave Hansen) * tag 'pci-v7.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: MAINTAINERS: Orphan Altera PCIe controller driver sparc/PCI: Initialize msi_addr_mask for OF-created PCI devices powerpc/pci: Initialize msi_addr_mask for OF-created PCI devices
2026-03-06arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbersGeert Uytterhoeven
SPI interrupts are in the range 0-987. Extended SPI interrupts should use GIC_ESPI, instead of abusing GIC_SPI with a manual offset of 4064. Fixes: 63500d12cf76d003 ("arm64: dts: renesas: Add R8A78000 SoC support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/1f9dd274720ea1b66617a5dd84f76c3efc829dc8.1772641415.git.geert+renesas@glider.be
2026-03-06arm64: dts: renesas: rzg3s-smarc-som: Set bypass for Versa3 PLL2Claudiu Beznea
The default settings for the Versa3 device on the Renesas RZ/G3S SMARC SoM board have PLL2 disabled. PLL2 was later enabled together with audio support, as it is required to support both 44.1 kHz and 48 kHz audio. With PLL2 enabled, it was observed that Linux occasionally either hangs during boot (the last log message being related to the I2C probe) or randomly crashes. This was mainly reproducible on cold boots. During debugging, it was also noticed that the Unicode replacement character (�) sometimes appears on the serial console. Further investigation traced this to the configuration applied through the Versa3 register at offset 0x1c, which controls PLL enablement. The appearance of the Unicode replacement character suggested an issue with the SoC reference clock. The RZ/G3S reference clock is provided by the Versa3 clock generator (REF output). After checking with the Renesas Versa3 hardware team, it was found that this is related to the PLL2 lock bit being set through the renesas,settings DT property. The PLL lock bit must be set to avoid unstable clock output from the PLL. However, due to the Versa3 hardware design, when a PLL lock bit is set, all outputs (including the REF clock) are temporarily disabled until the configured PLLs become stable. As an alternative, the bypass bit can be used. This does not interrupt the PLL2 output or any other Versa3 outputs, but it may result in temporary instability on PLL2 output while the configuration is applied. Since PLL2 feeds only the audio path and audio is not used during early boot, this is acceptable and does not affect system boot. Drop the PLL2 lock bit and set the bypass bit instead. This has been tested with more than 1000 cold boots. Fixes: a94253232b04 ("arm64: dts: renesas: rzg3s-smarc-som: Add versa3 clock generator node") Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260302135703.162601-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g087: Fix CPG register region sizesLad Prabhakar
The CPG register regions were incorrectly sized. Update them to match the actual hardware specification: - First region (0x80280000): 0x1000 -> 0x10000 (64kiB) - Second region (0x81280000): 0x9000 -> 0x10000 (64kiB) Fixes: 4b3d31f0b81fe ("arm64: dts: renesas: Add initial SoC DTSI for the RZ/N2H SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260213131742.3606334-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g077: Fix CPG register region sizesLad Prabhakar
The CPG register regions were incorrectly sized. Update them to match the actual hardware specification: - First region (0x80280000): 0x1000 -> 0x10000 (64kiB) - Second region (0x81280000): 0x9000 -> 0x10000 (64kiB) Fixes: d17b34744f5e4 ("arm64: dts: renesas: Add initial support for the Renesas RZ/T2H SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260213131742.3606334-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g057: Remove wdt{0,2,3} nodesFabrizio Castro
The HW user manual for the Renesas RZ/V2H(P) SoC (a.k.a r9a09g057) states that only WDT1 is supposed to be accessed by the CA55 cores. WDT0 is supposed to be used by the CM33 core, WDT2 is supposed to be used by the CR8 core 0, and WDT3 is supposed to be used by the CR8 core 1. Remove wdt{0,2,3} from the SoC specific device tree to make it compliant with the specification from the HW manual. This change is harmless as there are currently no users of the wdt{0,2,3} device tree nodes, only the wdt1 node is actually used. Fixes: 095105496e7d ("arm64: dts: renesas: r9a09g057: Add WDT0-WDT3 nodes") Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260203124247.7320-3-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: rzv2-evk-cn15-sd: Add ramp delay for SD0 regulatorLad Prabhakar
Set an appropriate ramp delay for the SD0 I/O voltage regulator in the CN15 SD overlay to make UHS-I voltage switching reliable during card initialization. This issue was observed on the RZ/V2H EVK, while the same UHS-I cards worked on the RZ/V2N EVK without problems. Adding the ramp delay makes the behavior consistent and avoids SD init timeouts. Before this change SD0 could fail with: mmc0: error -110 whilst initialising SD card With the delay in place UHS-I cards enumerate correctly: mmc0: new UHS-I speed SDR104 SDXC card at address aaaa mmcblk0: mmc0:aaaa SR64G 59.5 GiB mmcblk0: p1 Fixes: 3d6c2bc7629c8 ("arm64: dts: renesas: Add CN15 eMMC and SD overlays for RZ/V2H and RZ/V2N EVKs") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260123225957.1007089-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: rzt2h-n2h-evk: Add ramp delay for SD0 card regulatorLad Prabhakar
Add a ramp delay of 60 uV/us to the vqmmc_sdhi0 voltage regulator to fix UHS-I SD card detection failures. Measurements on CN78 pin 4 showed the actual voltage ramp time to be 21.86ms when switching between 3.3V and 1.8V. A 25ms ramp delay has been configured to provide adequate margin. The calculation is based on the voltage delta of 1.5V (3.3V - 1.8V): 1500000 uV / 60 uV/us = 25000 us (25ms) Prior to this patch, UHS-I cards failed to initialize with: mmc0: error -110 whilst initialising SD card After this patch, UHS-I cards are properly detected on SD0: mmc0: new UHS-I speed SDR104 SDXC card at address aaaa mmcblk0: mmc0:aaaa SR64G 59.5 GiB Fixes: d065453e5ee09 ("arm64: dts: renesas: rzt2h-rzn2h-evk: Enable SD card slot") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260123225957.1007089-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faultsPiotr Jaroszynski
contpte_ptep_set_access_flags() compared the gathered ptep_get() value against the requested entry to detect no-ops. ptep_get() ORs AF/dirty from all sub-PTEs in the CONT block, so a dirty sibling can make the target appear already-dirty. When the gathered value matches entry, the function returns 0 even though the target sub-PTE still has PTE_RDONLY set in hardware. For a CPU with FEAT_HAFDBS this gathered view is fine, since hardware may set AF/dirty on any sub-PTE and CPU TLB behavior is effectively gathered across the CONT range. But page-table walkers that evaluate each descriptor individually (e.g. a CPU without DBM support, or an SMMU without HTTU, or with HA/HD disabled in CD.TCR) can keep faulting on the unchanged target sub-PTE, causing an infinite fault loop. Gathering can therefore cause false no-ops when only a sibling has been updated: - write faults: target still has PTE_RDONLY (needs PTE_RDONLY cleared) - read faults: target still lacks PTE_AF Fix by checking each sub-PTE against the requested AF/dirty/write state (the same bits consumed by __ptep_set_access_flags()), using raw per-PTE values rather than the gathered ptep_get() view, before returning no-op. Keep using the raw target PTE for the write-bit unfold decision. Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT range may become the effective cached translation and software must maintain consistent attributes across the range. Fixes: 4602e5757bcc ("arm64/mm: wire up PTE_CONT for user mappings") Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Zi Yan <ziy@nvidia.com> Cc: Breno Leitao <leitao@debian.org> Cc: stable@vger.kernel.org Reviewed-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: James Houghton <jthoughton@google.com> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Breno Leitao <leitao@debian.org> Signed-off-by: Piotr Jaroszynski <pjaroszynski@nvidia.com> Acked-by: Balbir Singh <balbirs@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-06KVM: arm64: Remove the redundant ISB in __kvm_at_s1e2()Zenghui Yu (Huawei)
We already have an ISB in __kvm_at() to make the address translation result visible to subsequent reads of PAR_EL1. Remove the redundant one right after it. Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260306074422.47694-1-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-06KVM: arm64: Fix vma_shift staleness on nested hwpoison pathFuad Tabba
When user_mem_abort() handles a nested stage-2 fault, it truncates vma_pagesize to respect the guest's mapping size. However, the local variable vma_shift is never updated to match this new size. If the underlying host page turns out to be hardware poisoned, kvm_send_hwpoison_signal() is called with the original, larger vma_shift instead of the actual mapping size. This signals incorrect poison boundaries to userspace and breaks hugepage memory poison containment for nested VMs. Update vma_shift to match the truncated vma_pagesize when operating on behalf of a nested hypervisor. Fixes: fd276e71d1e7 ("KVM: arm64: nv: Handle shadow stage 2 page faults") Signed-off-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260304162222.836152-3-tabba@google.com [maz: simplified vma_shift assignment from the original patch] Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-06parisc: Fix initial page table creation for bootHelge Deller
The KERNEL_INITIAL_ORDER value defines the initial size (usually 32 or 64 MB) of the page table during bootup. Up until now the whole area was initialized with PTE entries, but there was no check if we filled too many entries. Change the code to fill up with so many entries that the "_end" symbol can be reached by the kernel, but not more entries than actually fit into the initial PTE tables. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v6.0+
2026-03-06parisc: Check kernel mapping earlier at bootupHelge Deller
The check if the initial mapping is sufficient needs to happen much earlier during bootup. Move this test directly to the start_parisc() function and use native PDC iodc functions to print the warning, because panic() and printk() are not functional yet. This fixes boot when enabling various KALLSYSMS options which need much more space. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v6.0+
2026-03-06parisc: Increase initial mapping to 64 MB with KALLSYMSHelge Deller
The 32MB initial kernel mapping can become too small when CONFIG_KALLSYMS is used. Increase the mapping to 64 MB in this case. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v6.0+
2026-03-06RISC-V: KVM: Check host Ssaia extension when creating AIA irqchipAnup Patel
The KVM user-space may create KVM AIA irqchip before checking VCPU Ssaia extension availability so KVM AIA irqchip must fail when host does not have Ssaia extension. Fixes: 89d01306e34d ("RISC-V: KVM: Implement device interface for AIA irqchip") Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260120080013.2153519-4-anup.patel@oss.qualcomm.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: Fix error code returned for Ssaia ONE_REGAnup Patel
Return -ENOENT for Ssaia ONE_REG when Ssaia is not enabled for a VCPU. This will make Ssaia ONE_REG error codes consistent with other ONE_REG interfaces of KVM RISC-V. Fixes: 2a88f38cd58d ("RISC-V: KVM: return ENOENT in *_one_reg() when reg is unknown") Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260120080013.2153519-3-anup.patel@oss.qualcomm.com Signed-off-by: Anup Patel <anup@brainfault.org>
generated by cgit v1.2.3 (git 2.0.4) at 2026-03-23 17:29:28 +0000