summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-03-10arm64: boot: dts: ti: k3-am62l3-evm: enable wkup_uart0_target nodeKendall Willis
Change the status of the wkup_uart0_target node to enabled. The node sets the UART SYSS register to allow wakeup from WKUP UART in DeepSleep low power mode. Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Kendall Willis <k-willis@ti.com> Link: https://patch.msgid.link/20260219-v6-19-wkup-uart-wakeup-v4-4-eda09dce5623@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-10arm64: boot: dts: ti: k3-am62l3-evm: define wkup_uart0 pinsKendall Willis
Add the pin definition for the wkup_uart0 node. Signed-off-by: Kendall Willis <k-willis@ti.com> Link: https://patch.msgid.link/20260219-v6-19-wkup-uart-wakeup-v4-3-eda09dce5623@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-10arm64: boot: dts: ti: k3-am62l-wakeup: create label for wkup_uart0 target-moduleKendall Willis
Add label to the target-module node so that it can easily be referenced. The node specifically configures the SYSCONFIG related registers for WKUP UART. Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Kendall Willis <k-willis@ti.com> Link: https://patch.msgid.link/20260219-v6-19-wkup-uart-wakeup-v4-2-eda09dce5623@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-10arm64: dts: ti: k3-am62l: include WKUP_UART0 in wakeup peripheral windowKendall Willis
WKUP_UART0 is apart of the wakeup peripherals and has a range from 0x002B300000 to 0x002B3001FF. Expand the wakeup peripheral window to include WKUP_UART0. Fixes: 5f016758b0ab ("arm64: dts: ti: k3-am62l: add initial infrastructure") Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Kendall Willis <k-willis@ti.com> Link: https://patch.msgid.link/20260219-v6-19-wkup-uart-wakeup-v4-1-eda09dce5623@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-10arm64: dts: ti: k3-am62d2-evm: Set wakeup-source system-statesKendall Willis
The CANUART pins of mcu_mcan0, mcu_mcan1, mcu_uart0 and wkup_uart0 are powered during Partial-IO and I/O Only + DDR and are capable of waking up the system in these states. Specify the states in which these units can do a wakeup on this board. Note that the UARTs are not capable of wakeup in Partial-IO because of of a UART mux on the board not being powered during Partial-IO. Add pincontrol definitions for mcu_mcan0 and mcu_mcan1 for wakeup from Partial-IO. Add these as wakeup pinctrl entries for both devices. Signed-off-by: Kendall Willis <k-willis@ti.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://patch.msgid.link/20260212-am62d-can-wkup-dts-v1-1-d2de17e1f303@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-10arm64: dts: ti: k3-am62-phycore-som: Add 128MiB of global CMAWadim Egorov
Reserve 128MiB of global CMA which is also marked as re-usable so that OS can also use the same if peripheral drivers are not using the same. Based on the use case described in commit c43dd2fe5316 ("arm64: dts: ti: k3-am62x-sk-common: Reserve 128MiB of global CMA"). Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20260213053806.219495-1-w.egorov@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-10riscv: dts: spacemit: Add 'linux,pci-domain' to PCIe nodes for K1Chukun Pan
The SpacemiT K1 SoC has 3 PCIe EP controller nodes. Add the 'linux,pci-domain' property to assign a PCI domain number to each of the controllers instead of assigning it randomly. This creates a stable sysfs path, allowing userspace scripts to reliably target specific PCIe devices (such as PCIe NICs). Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Reviewed-by: Yixun Lan <dlan@kernel.org> Link: https://lore.kernel.org/r/20260309030000.1157040-1-amadeus@jmu.edu.cn Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-03-10arm64: dts: rockchip: Enable GPU on rk3566-pinenoteSamuel Holland
The GPU is most useful when used together with the EBC on the PineNote, which is not yet described. But there's no reason not to define the GPU already as the hardware is present and could be used without the EBC. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Diederik de Haas <diederik@cknow-tech.com> Link: https://patch.msgid.link/20260305120620.173600-1-diederik@cknow-tech.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-09arm64: dts: qcom: correct RBR opp entryDmitry Baryshkov
DisplayPort Reduced Bit Rate uses link rate of 1.62 Gbps, the main link clock should be 162 MHz. Having the incorrect frequency (160 MHz) in the OPP table will result in selecting wrong link frequency. Correct the entry in the OPP table. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260304-msm-fix-rbr-v1-1-b9eba986eaef@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm64: dts: qcom: monaco-evk: Enable the secondary USB controllerSwati Agarwal
Enable the secondary USB controller connected to micro usb port in OTG mode on Monaco EVK platform. Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260303082157.523847-4-swati.agarwal@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm64: dts: qcom: monaco: Add role-switch support and HS endpoint for ↵Swati Agarwal
secondary USB controller Enable usb-role-switch for the secondary HS USB controller on Monaco. Additionally, add a port node with an HS endpoint so the controller can be linked through the DT graph to the corresponding connector. Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260303082157.523847-3-swati.agarwal@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm64: dts: qcom: monaco-evk: Enable GPIO expander interrupt for Monaco EVKSwati Agarwal
Enable PCA9538 expander as interrupt controller on Monaco EVK and configure the corresponding TLMM pins via pinctrl to operate as GPIO inputs with internal pull-ups. Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260303082157.523847-2-swati.agarwal@oss.qualcomm.com [bjorn: Reordered nodes under &tlmm] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm64: dts: qcom: sdm845: Introduce camera master clock pinctrlDavid Heidelberg
Put clock pins configuration for camera master clock into the dtsi. Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://lore.kernel.org/r/20260114-sdm845-mclk-v3-1-c9351deaf4f2@ixit.cz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm64: dts: qcom: qcm6490-idp: add and enable BT nodeJanaki Ramaiah Thota
Add the PMU node for WCN6750 present on the qcm6490-idp board and assign its power outputs to the Bluetooth module. In WCN6750 module sw_ctrl and wifi-enable pins are handled in the wifi controller firmware. Therefore, it is not required to have those pins' entries in the PMU node. Signed-off-by: Janaki Ramaiah Thota <janaki.thota@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260203071807.764036-1-janaki.thota@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm64: dts: qcom: monaco-evk: Enable SDHC1 for eMMCLoic Poulain
Monaco EVK has onboard eMMC, that can be used either as primary boot storage or as secondary storage when booting from UFS. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260116214354.256878-3-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm64: dts: qcom: monaco: Complete SDHC definitionLoic Poulain
Add the missing SDHC properties required to enable HS200, HS400, and HS400 Enhanced Strobe modes, as supported by this controller. Select the proper default pinctrls. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260116214354.256878-2-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm64: dts: qcom: talos: add ETR deviceJie Gan
Add the TMC ETR device to store collected trace data in DDR memory. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260128-enable-etr-on-talos-v2-1-ba77063d6b62@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-09arm: dts: ti: omap: align node patterns with established conventionCharan Pedumuru
Update OMAP DTS node patterns to match established conventions. Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com> Link: https://patch.msgid.link/20260123-ti-phy-v4-1-b557e2c46e6f@gmail.com Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2026-03-09x86/virt/sev: Keep the RMP table bookkeeping area mappedTom Lendacky
In preparation for delayed SNP initialization and disablement on shutdown, the RMP will need to be cleared each time SNP is disabled. Maintain the mapping to the RMP bookkeeping area to avoid mapping and unmapping it each time and any possible errors that may arise from that. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260309180053.2389118-4-tycho@kernel.org
2026-03-09x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_ENTycho Andersen (AMD)
WBINVD is required before SNP_INIT(_EX), but not before setting MSR_AMD64_SYSCFG_SNP_EN, since the ccp driver already does its own WBINVD before SNP_INIT (and this one would be too early for that anyway...). Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260309180053.2389118-3-tycho@kernel.org
2026-03-09x86/virt/sev: Drop support for SNP hotplugTycho Andersen (AMD)
During an SNP_INIT(_EX), the SEV firmware checks that all CPUs have the SNP syscfg bit set, and fails if they do not. As such, it does not make sense to have offline CPUs: the firmware will fail initialization because of the offlined ones that the kernel did not initialize. Further, there is a bug: during SNP_INIT(_EX) the firmware requires the MFDM syscfg bit to be set in addition to having SNP enabled, which the previous hotplug code did not do. Since k8_check_syscfg_dram_mod_en() enforces this be cleared, hotplug wouldn't work. Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260309180053.2389118-2-tycho@kernel.org
2026-03-09crypto: 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-09lib/crypto: arm64/aes: Migrate optimized CBC-based MACs into libraryEric Biggers
Instead of exposing the arm64-optimized CMAC, XCBC-MAC, and CBC-MAC code via arm64-specific crypto_shash algorithms, instead just implement the aes_cbcmac_blocks_arch() library function. This is much simpler, it makes the corresponding library functions be arm64-optimized, and it fixes the longstanding issue where this optimized code was disabled by default. The corresponding algorithms still remain available through crypto_shash, but individual architectures no longer need to handle it. Note that to be compatible with the library using 'size_t' lengths, the type of the return value and 'blocks' parameter to the assembly functions had to be changed to 'size_t', and the assembly code had to be updated accordingly to use the corresponding 64-bit registers. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20260218213501.136844-6-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-03-09lib/crypto: arm64/aes: Move assembly code for AES modes into libaesEric Biggers
To migrate the support for CBC-based MACs into libaes, the corresponding arm64 assembly code needs to be moved there. However, the arm64 AES assembly code groups many AES modes together; individual modes aren't easily separable. (This isn't unique to arm64; other architectures organize their AES modes similarly.) Since the other AES modes will be migrated into the library eventually too, just move the full assembly files for the AES modes into the library. (This is similar to what I already did for PowerPC and SPARC.) Specifically: move the assembly files aes-ce.S, aes-modes.S, and aes-neon.S and their build rules; declare the assembly functions in <crypto/aes.h>; and export the assembly functions from libaes. Note that the exports and public declarations of the assembly functions are temporary. They exist only to keep arch/arm64/crypto/ working until the AES modes are fully moved into the library. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20260218213501.136844-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-03-09crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bitEric Biggers
Since the 'enc_after' argument to neon_aes_mac_update() and ce_aes_mac_update() has type 'int', it needs to be accessed using the corresponding 32-bit register, not the 64-bit register. The upper half of the corresponding 64-bit register may contain garbage. Fixes: 4860620da7e5 ("crypto: arm64/aes - add NEON/Crypto Extensions CBCMAC/CMAC/XCBC driver") Cc: stable@vger.kernel.org Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20260218213501.136844-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-03-09arm64: dts: ti: k3-am69-aquila-clover: Fix DP regulator enable GPIOFranz Schnyder
Correct the DP regulator enable GPIO to index 21. The 3.3V DP regulator was not being enabled by the assigned GPIO, as it is routed to GPIO index 21 and not 37, which was causing instability with displays connected over DP or via an active DP-to-HDMI adapter. Fixes: 9f748a6177e1 ("arm64: dts: ti: am69-aquila: Add Clover") Cc: stable@vger.kernel.org Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20260202083604.325060-3-fra.schnyder@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-09arm64: dts: ti: k3-am69-aquila-dev: Fix DP regulator enable GPIOFranz Schnyder
Correct the DP regulator enable GPIO to index 21. The 3.3V DP regulator was not being enabled by the assigned GPIO, as it is routed to GPIO index 21 and not 37, which was causing instability with displays connected over DP or via an active DP-to-HDMI adapter. Fixes: 39ac6623b1d8 ("arm64: dts: ti: Add Aquila AM69 Support") Cc: stable@vger.kernel.org Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20260202083604.325060-2-fra.schnyder@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-09arm64: dts: ti: k3-am62l: support cpufreq scalingDhruva Gole
Enable CPUFreq support for AM62L SoC by adding the relevant OPP efuse table syscon for speed grade detection. Add the operating-points-v2 table with CPU frequency steps from 200MHz to 1.25GHz. Specify the CPU clocks to reference the SCMI clock controller for frequency scaling. Signed-off-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Kendall Willis <k-willis@ti.com> Link: https://patch.msgid.link/20260122-am62l-cpufreq-v5-1-65c50af71681@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2026-03-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.0-rc3Alexei Starovoitov
Cross-merge BPF and other fixes after downstream PR. No conflicts. Signed-off-by: Alexei Starovoitov <ast@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-08x86/local: Remove trailing semicolon from _ASM_XADD in local_add_return()Uros Bizjak
Remove the trailing semicolon from the inline assembly statement in local_add_return(). The _ASM_XADD macro already expands to a complete instruction, making the extra semicolon unnecessary. More importantly, the stray semicolon causes GCC to treat the inline asm as containing multiple instructions, which can skew its internal instruction count estimation and affect optimization heuristics. No functional change intended. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260308171250.7278-1-ubizjak@gmail.com
2026-03-08arm: dts: microchip: remove unused #address-cells/#size-cells from sam9x60 ↵Charan Pedumuru
udc node The UDC node does not define any child nodes, so the "#address-cells" and "#size-cells" properties are unnecessary. Remove these unused properties to simplify the devicetree node and keep it consistent with DT conventions. Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com> Link: https://lore.kernel.org/r/20260307-atmel-usb-v3-1-3dc48fe772be@gmail.com Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> [claudiu.beznea: s/at91/microchip in commit title] Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2026-03-08powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIGThomas Weißschuh
When CONFIG_MODULE_SIG is disabled set_module_sig_enforced() is defined as an empty stub, so the check is unnecessary. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
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-07arm64: dts: exynos: gs101-pixel-common: add Maxim MAX77759 fuel gaugeAndré Draszik
On Pixel 6 (and Pro), a MAX77759 companion PMIC for USB Type-C applications is used, which contains four functional blocks (at distinct I2C addresses): * top (including GPIO & NVMEM) * charger * fuel gauge * TCPCi This change adds the fuel gauge. Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/20260302-max77759-fg-dts-v2-1-12f1109a6fee@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
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-07x86/asm: Use inout "+" asm onstraint modifiers in __iowrite32_copy()Uros Bizjak
Use inout "+" asm constraint modifiers to simplify asm operands. No functional changes intended. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com> Link: https://patch.msgid.link/20251216105134.248196-1-ubizjak@gmail.com
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
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-15 23:51:17 +0000