summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-06-11LoongArch: KVM: Remove some middle FPU statesBibo Mao1-33/+4
With max VM supported FPU type enabled, if VM supports LASX, there is only NONE --> LASX, no middle FPU state such as NONE --> FPU --> LASX or NONE --> FPU --> LSX --> LASX. Here remove the middle FPU states in function kvm_own_lsx() and kvm_own_lasx(). And it becomes simpler than before. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-06-11LoongArch: KVM: Enable FPU with max supported FPU typeBibo Mao3-22/+7
There are three FPU types FPU/LSX/LASX, which represents FPU64, FPU128 and FPU256, and now lazy FPU method is used with FPU enabling. There are three different HW FPU exception code with different FPU type. The exising method is to enable specified FPU type with responding FPU exeception. Supposing application uses FPU64 and FPU256, there will be FPU256 exception when FPU256 type is used. Here enable FPU with the max VM supported type directly, so it can avoid unnecessary FPU exception in future if further FPU type is used. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-06-11LoongArch: KVM: Add separate KVM_REQ_LBT_LOAD bitBibo Mao3-12/+11
There are different structures with FPU and LBT register restore, with FPU the structure is vcpu::arch::fpu, with LBT the structure is vcpu:: arch::lbt. Moreover, FPU/LSX/LASX saving and restoring share the common structure vcpu::arch::fpu. New request bit KVM_REQ_LBT_LOAD is used for LBT register restore, and rename KVM_REQ_AUX_LOAD with KVM_REQ_FPU_LOAD for FPU register restore. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-06-11KVM: s390: vsie: Use mmu cache to allocate rmapClaudio Imbrenda3-12/+14
Use kvm_s390_mmu_cache_alloc_rmap() to allocate the rmap in gmap_insert_rmap(), instead of a normal kzalloc_obj() with GFP_ATOMIC. This guarantees forward progress. Fixes: a2c17f9270cc ("KVM: s390: New gmap code") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260611104850.110313-6-imbrenda@linux.ibm.com>
2026-06-11KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault()Claudio Imbrenda1-22/+35
Add missing radix_tree_preload() in _gaccess_shadow_fault() to guarantee forward progress. The core of _gaccess_shadow_fault() has been split into ___gaccess_shadow_fault() in order to simplify locking. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260611104850.110313-5-imbrenda@linux.ibm.com>
2026-06-11KVM: s390: vsie: Fix allocation of struct vsie_rmapClaudio Imbrenda1-1/+1
The allocation size for struct vsie_rmap in kvm_s390_mmu_cache_topup() was wrong due to a copy-paste error. Fix it by using the type name. Fixes: 12f2f61a9e1a ("KVM: s390: KVM page table management functions: allocation") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260611104850.110313-4-imbrenda@linux.ibm.com>
2026-06-11KVM: s390: Fix unlikely race in try_get_locked_pte()Claudio Imbrenda1-3/+3
Fix an unlikely race in try_get_locked_pte(), which could have happened if puds or pmds get unmapped between the p?dp_get() and p?d_offset() functions. Fixes: 89fa757931dc ("KVM: s390: Avoid potentially sleeping while atomic when zapping pages") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260611104850.110313-3-imbrenda@linux.ibm.com>
2026-06-11KVM: s390: Silence potential warnings in _gmap_crstep_xchg_atomic()Claudio Imbrenda1-1/+10
While dat_crstep_xchg_atomic() is marked as __must_check, in this particular case the return value should be ignored. Silence potential compiler warnings with a pointless check, and add a comment to explain the situation. Fixes: d1adc098ce08 ("KVM: s390: Fix _gmap_crstep_xchg_atomic()") CC: stable@vger.kernel.org # 7.1 Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260611104850.110313-2-imbrenda@linux.ibm.com>
2026-06-11x86/cpu: Make CONFIG_X86_CX8 unconditionalIngo Molnar3-3/+1
I.e. from now on it's a boot time requirement for the CPU to support it. ( This was preceded by the removal of all non-CX8 platform build options, so it should have no functional effects in theory. ) Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ahmed S . Darwish <darwi@linutronix.de> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: H . Peter Anvin <hpa@zytor.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250425084216.3913608-14-mingo@kernel.org
2026-06-11x86/cpu: Remove unused !CONFIG_X86_TSC codeIngo Molnar6-38/+5
Now that the Kconfig space always enables CONFIG_X86_TSC (on x86), remove !CONFIG_X86_TSC code from the x86 arch code. We still keep the Kconfig option to catch any eventual code still pending in maintainer or non-mainline trees, plus some drivers have raw TSC timestamping hacks that use CONFIG_X86_TSC. It's also still possible to disable TSC support runtime. Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ahmed S . Darwish <darwi@linutronix.de> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: H . Peter Anvin <hpa@zytor.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250425084216.3913608-13-mingo@kernel.org
2026-06-11m68k: stmark2: enable DACs outputsAngelo Dureghello1-0/+7
Enabled DAC0 and DAC1 outpus disabling shared ADC inputs on ADC3 and ADC7. Reviewed-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: stmark2: add mcf5441x DAC platform devicesAngelo Dureghello1-0/+20
Add mcf5441x DAC platform devices. Reviewed-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: stmark2: use ioport.h macros for resourcesAngelo Dureghello1-15/+5
Change resource declaration using DEFINE_RES_*() macros. DEFINE_DMA_RES() is for a single dma channel, not a range, so used twice. Also, some drivers assume IRQ resources are from index 1, so just to stay uniform, moved IRQ resource at index 1. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: mcf5441x: add CCR MISCCR2 bitfieldsAngelo Dureghello1-0/+17
Add CCR MISCCR2 register bitfields. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: mcf5441x: add CCM registersAngelo Dureghello1-0/+20
Add CCM module register offsets. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: add DAC modules base addressesAngelo Dureghello1-0/+5
Add DAC controller 0 and 1 base addresses. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: mcf5441x: add clock for DAC channel 1Angelo Dureghello1-0/+3
Add missing clock for mcf5441x DAC channel 1. Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11m68k: mcf5441x: fix clocks numberingAngelo Dureghello1-9/+9
Fix clocks numbering, set correct values for eport and DAC, as per RM Rev 5, 05/2018, table 9.5. Fixes: bea8bcb12da09 ("m68knommu: Add support for the Coldfire m5441x.") Fixes: 007f84ede6e3e ("m68k: coldfire: remove private clk_get/clk_put") Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
2026-06-11crypto: exynos-rng - Remove exynos-rng driverEric Biggers2-2/+0
This driver has no purpose. It doesn't feed into the Linux RNG, nor does it implement the hwrng interface. It is accessible only via the "rng" algorithm type of AF_ALG, which isn't used in practice. Everyone uses either the Linux RNG, or rarely /dev/hwrng. Moreover, this is a PRNG whose only source of entropy is the 160-bit seed the user passes in. So this can be used only by a user who already has a source of cryptographically secure random numbers, such as /dev/random. Which they can, and do, just use in the first place. Just remove this driver. There's no need to keep useless code around. Note that the other crypto_rng drivers in drivers/crypto/ are similarly unused and are being removed too. This commit just handles exynos-rng. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11hwrng: hisi-trng - Move hisi-trng into drivers/char/hw_random/Eric Biggers1-1/+1
Since this file just implements a hwrng driver, move it into drivers/char/hw_random/. Rename the kconfig option accordingly as well. Note that this moves the file back to its original location. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-11crypto: loongson - Remove broken and unused loongson-rngEric Biggers2-2/+0
The loongson-rng rng_alg has several vulnerabilities, including not providing forward security, and a use-after-free bug due to the use of wait_for_completion_interruptible(). Meanwhile, the rng_alg framework doesn't really have any purpose in the first place other than to access the software algorithms crypto/drbg.c and crypto/jitterentropy.c. Hardware-specific rng_algs have no in-kernel user, and unlike hwrng there's no feed into the actual Linux RNG. As such, there's really no point to this code. There are of course other rng_alg drivers that are similarly unused, but they're similarly in the process of being phased out, e.g. https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org Given that, there's no point in fixing forward these vulnerabilities, and it makes much more sense to simply roll back the addition of this driver. If this platform provides TRNG (not PRNG) functionality, it could make sense to add a hwrng driver, but it would be quite different. Link: https://lore.kernel.org/linux-crypto/20260525145939.GC2018@quark/ Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-06-10Merge tag 'imx-dt64-7.2-part2' of ↵Arnd Bergmann1-6/+6
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/dt i.MX arm64 device tree changes for v7.2 (part2) - Revert the 32-bit non-prefetchable PCIe window from 3 GiB back to 1 GiB to prevent overlap between inbound DMA address space and low system RAM. Such overlap can cause DMA transactions to be routed to a BAR on the same host bridge instead of system memory. * tag 'imx-dt64-7.2-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux: arm64: dts: lx2160a-rev2: avoid 32-bit pcie window system ram overlap Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-06-10Merge tag 'imx-dt64-7.2' of ↵Arnd Bergmann121-267/+13310
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/dt i.MX dt64 changes for v7.2 New Board Support: Added 15+ new boards including i.MX95 (FRDM PRO, Aquila, Audio Board v2), i.MX93/91 (Variscite DART/VAR-SOM), i.MX8 (TQMa8QM, SolidRun i.MX8DXL HummingBoard), Toradex Verdin Zinnia variants, and LX2160A Half Twins. PCIe Improvements: Added Root Port nodes and PERST properties across iMX8MM/MP/MQ/DXL/QM/QXP/95, new PCIe support for iMX94/943, common M.2 PCIe overlay, fixed outbound address space configuration Graphics, Camera and Display: Mali G310 GPU for iMX952, HDMI for iMX8MP PhyBoard, extensive DH Electronics panel overlays, Extensive overlay ecosystem for DH Electronics iMX8MP boards, PhyBoard PEB-AV-18, camera (OV5640), and ethernet configuration overlays Peripheral Support: S32G2/G3 PIT/ADC/PWM, iMX8ULP CSI/ISI, iMX943 SD WiFi, USB hub for LX2160A, TPM/CAN/ADC support for Variscite boards, Bluetooth and UART enhancements for Toradex SMARC boards. Enhancements Added gpio-line-namesacross PhyBOARD platforms. Watchdog reset pinctrl configurations for iMX91 boards, Ethernet PHY reset GPIO support. Bug Fixes: Corrected DDR PMU interrupts, SMMU registers, watchdog addresses, interrupt flags, GPIO configurations, PHY reset handling, and RS485 polarity, USDHC signal configurations for PhyCORE SoMs. * tag 'imx-dt64-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux: (110 commits) arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlays arm64: dts: imx93-var-som-symphony: enable ADC arm64: dts: imx93-var-som-symphony: enable TPM3 PWM arm64: dts: imx93-var-som-symphony: keep RGB_SEL low arm64: dts: imx93-var-som-symphony: enable UART7 arm64: dts: imx93-var-som-symphony: add TPM support arm64: dts: imx91-var-som-symphony: fix RGB_SEL handling arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc aliases arm64: dts: imx943-evk-sdwifi: add a new dtso to support SDIW612 WiFi arm64: dts: imx8mp-kontron: Fix GPIO for display power switch arm64: dts: freescale: imx95-aquila: Add Clover carrier board arm64: dts: freescale: add Aquila iMX95 support dt-bindings: arm: fsl: add Aquila iMX95 arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as well arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts dt-bindings: arm: fsl: Add i.MX95 19x19 FRDM PRO board arm64: dts: s32g: add PWM support for s32g2 and s32g3 arm64: dts: s32g3: Fix SWT8 watchdog address arm64: dts: imx95-var-dart-sonata: add CAN controller arm64: dts: imx95-var-dart-sonata: add TPM reset GPIO ... Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-06-10arm64: dts: lx2160a-rev2: avoid 32-bit pcie window system ram overlapJosua Mayer1-6/+6
A 3GB non-prefetchable PCIe bus window can overlap with inbound DMA addresses for low system RAM, so DMA transactions may be routed to a BAR on the same host bridge instead of memory. Change the 32-bit non-prefetchable PCIe window back from 3GB to 1GB on all controllers, avoiding that overlap while keeping the added 64-bit prefetchable region. This partially reverts commit 9ed301397090 ("arm64: dts: lx2160a-rev2: extend 32-bit and add 64-bit pci regions"). Fixes: 9ed301397090 ("arm64: dts: lx2160a-rev2: extend 32-bit and add 64-bit pci regions") Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/r/9e6326f6-dad1-4169-a63c-e62ee5b341f2@app.fastmail.com Signed-off-by: Josua Mayer <josua@solid-run.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-06-10s390/tishift: Convert __ashlti3(), __ashrti3(), __lshrti3() to CHeiko Carstens4-67/+73
There is no reason to have __ashlti3(), __ashrti3(), and __lshrti3() implemented in assembler. Convert them all to C, which allows the compiler to optimize the code if newer instructions allow that. Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/memmove: Optimize backward copy caseHeiko Carstens1-1/+23
memmove() copies byte wise for the backward copy case, when the mvc instruction cannot be used. This is quite slow, but can be optimized with the mvcrl instruction, which is available since z15. Some numbers (measured on a shared z16 LPAR) show that the new implementation is nearly always faster, except for the non realistic one and two byte cases: size old new 1 2ns 3ns 2 4ns 5ns 4 5ns 5ns 8 8ns 5ns 16 12ns 6ns 32 8ns 7ns 64 15ns 7ns 128 31ns 9ns 256 64ns 10ns 512 129ns 18ns 1024 250ns 19ns 2048 498ns 38ns Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/string: Convert memset(16|32|64)() to CHeiko Carstens7-70/+50
Convert memset(16|32|64)() from assembler to C, which should make it easier to read and change, if required. And it allows the compiler to optimize the code, and use different instructions, except for the used inline assemblies. Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/string: Convert memcpy() to CHeiko Carstens2-31/+34
Convert memcpy() from assembler to C, which should make it easier to read and change, if required. And it allows the compiler to optimize the code, and use different instructions, except for the used inline assemblies. Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/string: Convert memset() to CHeiko Carstens2-63/+61
Convert memset() from assembler to C, which should make it easier to read and change, if required. And it allows the compiler to optimize the code, and use different instructions, except for the used inline assemblies. Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/string: Convert memmove() to CHeiko Carstens2-41/+46
Convert memmove() from assembler to C, which should make it easier to read and change, if required. And it allows the compiler to optimize the code, and use different instructions, except for the used inline assemblies. Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/string: Add -ffreestanding compile option to string.oHeiko Carstens2-0/+10
Use -ffreestanding for string.o to avoid that the compiler generates calls into themselves for standard library functions like memset(). Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390: Add .noinstr.text to boot and purgatory linker scriptsHeiko Carstens2-0/+2
Upcoming changes will result in a .noinstr.text section within the boot and purgatory string.o binary. Explicitly add the new section to avoid orphaned warnings from the linker. Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/purgatory: Enforce z10 minimum architecture levelHeiko Carstens1-2/+4
The purgatory code is compiled without the -march option. This means the default architecture level of the compiler is used. This can cause problems, e.g. if instructions used in inline assemblies are for a higher architecture level than the default architecture level of the compiler. Use z10 as minimum architecture level, similar to the boot code, to enforce a defined architecture level set. Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10Merge branch 'rust-for-s390' into featuresAlexander Gordeev5-29/+53
Jan Polensky says: =================== Rust support on s390 requires a small set of architecture-specific pieces before the generic Rust kernel infrastructure can be used. The series wires up s390 as a Rust-capable 64-bit architecture, adds the missing assembly interfaces needed by Rust for WARN/BUG reporting and for static branches, adjusts bindgen parameters to avoid repr layout conflicts caused by packed and aligned s390 structures, and fixes issues discovered during testing. s390 currently requires rustc with support for -Zpacked-stack, and the minimum tool version gating is adjusted accordingly. Link: https://github.com/Rust-for-Linux/linux/issues/2 Tested against: rustc 1.96.0 (ac68faa20 2026-05-25) =================== Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390: Enable Rust supportJan Polensky2-11/+18
Enable building Rust code on s390 by wiring the architecture into the kernel Rust infrastructure. Add s390 to the Rust arch support documentation, provide the s390 Rust target and required compiler flags, and set the bindgen target for arch/s390. Adjust the Rust target generation and minimum rustc version gating so the s390 setup is handled explicitly. The Rust toolchain uses the "s390x" triple naming for the 64 bit target. Rust support is currently incompatible with CONFIG_EXPOLINE, which relies on compiler support for the -mindirect-branch= and -mfunction_return= options. Therefore, select HAVE_RUST only when EXPOLINE is disabled. Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Gary Guo <gary@garyguo.net> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/cmpxchg: Fix KASAN stack-out-of-bounds in atomic helpersJan Polensky1-4/+4
The __arch_cmpxchg1, __arch_cmpxchg2, __arch_xchg1, and __arch_xchg2 functions emulate 1-byte and 2-byte atomic operations using 4-byte cmpxchg instructions, since s390 lacks native 1/2-byte cmpxchg support. When KASAN is enabled, the READ_ONCE() operations in these functions trigger stack-out-of-bounds warnings because they perform 4-byte reads when only 1 or 2 bytes should be accessed. Mark these functions as __no_sanitize_or_inline to prevent KASAN instrumentation while maintaining correct functionality. This resolves the following KASAN error during rust_atomics KUnit tests: BUG: KASAN: stack-out-of-bounds in rust_helper_atomic_i8_xchg+0xb2/0xc0 Read of size 4 at addr 001bff7ffdbefcf0 by task kunit_try_catch/142 Reported-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Link: https://lore.kernel.org/rust-for-linux/CANiq72m4GVWFYqnxNtCHTPu7XcGewHB5LNwOoayTfnXs9pPbNg@mail.gmail.com/ Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/rust-for-linux/DITFTAVVHTNQ.380OHUHGTOI6M@garyguo.net/ Acked-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Gary Guo <gary@garyguo.net> Signed-off-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ↵Jan Polensky1-14/+19
ARCH_STATIC_BRANCH_ASM macros Rust static branch support needs the s390 jump label instruction sequence and __jump_table emission in a reusable form. The current implementation embeds the sequence directly in the C asm goto blocks, which cannot be shared with Rust. Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to describe the brcl sequences for the likely-false and likely-true cases and to emit the same __jump_table entries as before. Switch the existing C helpers to use the new macros to avoid duplication without changing the generated code. Acked-by: Gary Guo <gary@garyguo.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG supportJan Polensky1-0/+12
Rust WARN and BUG support relies on ARCH_WARN_ASM to emit __bug_table entries. On s390 the macro is missing, so Rust code cannot generate proper WARN/BUG metadata for the kernel's bug reporting infrastructure. Define ARCH_WARN_ASM to produce the same assembly sequence and __bug_table entry format as the existing s390 BUG handling, including the monitor call. Define ARCH_WARN_REACHABLE as empty since s390 does not provide reachability analysis for warning paths. Acked-by: Gary Guo <gary@garyguo.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-10Merge tag 'riscv-for-linux-7.1-rc8' of ↵Linus Torvalds4-12/+9
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: - Fix the implementation of the CFI branch landing pad control prctl()s to return -EINVAL if unknown control bits are set, rather than silently ignoring the request; and add a kselftest for this case - Fix unaligned access performance testing to happen earlier in boot, which fixes a performance regression in the lib/checksum code - Fix a binfmt_elf warning when dumping core (due to missing .core_note_name for CFI registers) * tag 'riscv-for-linux-7.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: cfi: reject unknown flags in PR_SET_CFI riscv: Fix fast_unaligned_access_speed_key not getting initialized riscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI
2026-06-10KVM: arm64: nv: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlbMarc Zyngier1-2/+14
Sashiko reports that there is a race between initialising vncr_tlb and making use of it, as we don't hold the mmu_lock at this point. Additionally, it identifies a memory leak, should userspace repeatedly invokes the KVM_RUN ioctl after a failure of kvm_arch_vcpu_run_pid_change(), as we assign vncr_tlb blindly on first run, irrespective of prior allocations. Slap the two bugs in one go by taking the kvm->mmu_lock on assigning vncr_tlb, preventing the race for good, and by checking that vncr_tlb is indeed NULL prior to allocation. Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://lore.kernel.org/r/20260607180815.85FBC1F00893@smtp.kernel.org Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260608081108.2244133-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-10sh: roll back Ecovec24/7724se Sound supportKuninori Morimoto2-0/+191
Due to a communication miss, the Ecovec24/7724se Sound support were removed. We need to keep them for a while, until they will support "DT-style". Roll back Ecovec24/7724se "platform data style", and its necessary header. Fixes: deadb855b694d ("sh: 7724se: remove FSI/AK4642/Simple-Audio-Card support") Fixes: 9cc93ebc85e71 ("sh: ecovec24: remove FSI/DA7210/Simple-Audio-Card support") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87v7br43vk.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPUWill Deacon2-0/+2
Commit fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata") states that Microsoft Azure Cobalt 100 CPU "is a Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore suffers from all the same errata.". So enable the workaround for the latest broadcast TLB invalidation bug on these parts. Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPUShanker Donthineni2-1/+3
NVIDIA Olympus cores are affected by the TLBI completion issue tracked as CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB sequence and ensure affected memory write effects are globally observed. Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same mitigation is enabled on affected Olympus systems. Also document the NVIDIA Olympus erratum in the arm64 silicon errata table and list it in the Kconfig help text. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLBMarc Zyngier1-21/+15
VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case. Both kvm_invalidate_vncr_ipa() and kvm_invalidate_vncr_va() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer. Solve this by introducing a new iterator built on top of the usual kvm_for_each_vcpu() that checks for both of the above conditions, and convert the two users to it. Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Link: https://lore.kernel.org/r/aiUvSbrWndQeUPc8@v4bel Fixes: 4ffa72ad8f37 ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Cc: stable@vger.kernel.org Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260607175745.297793-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-10arm64: errata: Mitigate TLBI errata on various Arm CPUsMark Rutland2-2/+66
A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10arm64: cputype: Add C1-Premium definitionsMark Rutland1-0/+2
Add cputype definitions for C1-Premium. These will be used for errata detection in subsequent patches. These values can be found in the C1-Premium TRM: https://developer.arm.com/documentation/109416/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10arm64: cputype: Add C1-Ultra definitionsMark Rutland1-0/+2
Add cputype definitions for C1-Ultra. These will be used for errata detection in subsequent patches. These values can be found in the C1-Ultra TRM: https://developer.arm.com/documentation/108014/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10Revert "arm64: mm: Unmap kernel data/bss entirely from the linear map"Will Deacon1-41/+4
This reverts commit 63e0b6a5b6934d6a919d1c65ea185303200a1874. Unmapping the kernel '.bss' appears to break KVM initialisation on some devices, breaking the boot on popular platforms such as RaspberryPi3 and 4. Revert this change for now so that we can revisit it in future. Reported-by: Mark Brown <broonie@kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/all/aicVyebkEMs6w6UV@sirena.co.uk Link: https://lore.kernel.org/r/a1b27e97-182c-485d-a448-56c19c5de2c2@samsung.com Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10Revert "arm64: mm: Defer remap of linear alias of data/bss"Will Deacon1-3/+3
This reverts commit 53205d56212cbff880a77497e25a0e44036d490a. Unmapping the kernel '.bss' appears to break KVM initialisation on some devices, breaking the boot on popular platforms such as RaspberryPi3 and 4. Revert this change for now so that we can revisit it in future. Reported-by: Mark Brown <broonie@kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/all/aicVyebkEMs6w6UV@sirena.co.uk Link: https://lore.kernel.org/r/a1b27e97-182c-485d-a448-56c19c5de2c2@samsung.com Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10arm64: tegra: Remove fallback compatible for GPCDMAAkhil R1-1/+1
Remove the fallback compatible string "nvidia,tegra186-gpcdma" for GPCDMA in Tegra264. Tegra186 compatible cannot work on Tegra264 because of the register offset changes and absence of the reset property. Fixes: 65ef237e4810 ("arm64: tegra: Add Tegra264 support") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-27 10:35:58 +0000