summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-01-23riscv: Add intermediate cast to 'unsigned long' in __get_user_asmNathan Chancellor1-1/+1
After commit bdce162f2e57 ("riscv: Use 64-bit variable for output in __get_user_asm"), there is a warning when building for 32-bit RISC-V: In file included from include/linux/uaccess.h:13, from include/linux/sched/task.h:13, from include/linux/sched/signal.h:9, from include/linux/rcuwait.h:6, from include/linux/mm.h:36, from include/linux/migrate.h:5, from mm/migrate.c:16: mm/migrate.c: In function 'do_pages_move': arch/riscv/include/asm/uaccess.h:115:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 115 | (x) = (__typeof__(x))__tmp; \ | ^ arch/riscv/include/asm/uaccess.h:198:17: note: in expansion of macro '__get_user_asm' 198 | __get_user_asm("lb", (x), __gu_ptr, label); \ | ^~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:218:9: note: in expansion of macro '__get_user_nocheck' 218 | __get_user_nocheck(x, ptr, __gu_failed); \ | ^~~~~~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:255:9: note: in expansion of macro '__get_user_error' 255 | __get_user_error(__gu_val, __gu_ptr, __gu_err); \ | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:285:17: note: in expansion of macro '__get_user' 285 | __get_user((x), __p) : \ | ^~~~~~~~~~ mm/migrate.c:2358:29: note: in expansion of macro 'get_user' 2358 | if (get_user(p, pages + i)) | ^~~~~~~~ Add an intermediate cast to 'unsigned long', which is guaranteed to be the same width as a pointer, before the cast to the type of the output variable to clear up the warning. Fixes: bdce162f2e57 ("riscv: Use 64-bit variable for output in __get_user_asm") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601210526.OT45dlOZ-lkp@intel.com/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260121-riscv-fix-int-to-pointer-cast-v1-1-b83eebe57c76@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-23x86: make page fault handling disable interrupts properlyCedric Xing1-10/+5
There's a big comment in the x86 do_page_fault() about our interrupt disabling code: * User address page fault handling might have reenabled * interrupts. Fixing up all potential exit points of * do_user_addr_fault() and its leaf functions is just not * doable w/o creating an unholy mess or turning the code * upside down. but it turns out that comment is subtly wrong, and the code as a result is also wrong. Because it's certainly true that we may have re-enabled interrupts when handling user page faults. And it's most certainly true that we don't want to bother fixing up all the cases. But what isn't true is that it's limited to user address page faults. The confusion stems from the fact that we have logic here that depends on the address range of the access, but other code then depends on the _context_ the access was done in. The two are not related, even though both of them are about user-vs-kernel. In other words, both user and kernel addresses can cause interrupts to have been enabled (eg when __bad_area_nosemaphore() gets called for user accesses to kernel addresses). As a result we should make sure to disable interrupts again regardless of the address range before returning to the low-level fault handling code. The __bad_area_nosemaphore() code actually did disable interrupts again after enabling them, just not consistently. Ironically, as noted in the original comment, fixing up all the cases is just not worth it, when the simple solution is to just do it unconditionally in one single place. So remove the incomplete case that unsuccessfully tried to do what the comment said was "not doable" in commit ca4c6a9858c2 ("x86/traps: Make interrupt enable/disable symmetric in C code"), and just make it do the simple and straightforward thing. Signed-off-by: Cedric Xing <cedric.xing@intel.com> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> Fixes: ca4c6a9858c2 ("x86/traps: Make interrupt enable/disable symmetric in C code") Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-01-23mips: Add support for PC32 relocations in vmlinuxArd Biesheuvel2-0/+4
MIPS supports PC32 relocations like most other architectures, which will be used by kallsyms to make its symbol references visible to the linker. Given that these are place-relative, they can be ignored by the 'relocs' tool, just like other PC type relocations. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260116093359.2442297-5-ardb+git@google.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-22arm64: dts: rockchip: Fix rk3588 PCIe range mappingsShawn Lin2-5/+5
The pcie bus address should be mapped 1:1 to the cpu side MMIO address, so that there is no same address allocated from normal system memory. Otherwise it's broken if the same address assigned to the EP for DMA purpose.Fix it to sync with the vendor BSP. Fixes: 0acf4fa7f187 ("arm64: dts: rockchip: add PCIe3 support for rk3588") Fixes: 8d81b77f4c49 ("arm64: dts: rockchip: add rk3588 PCIe2 support") Cc: stable@vger.kernel.org Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/1767600929-195341-2-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-22arm64: dts: rockchip: Fix rk356x PCIe range mappingsShawn Lin2-3/+3
The pcie bus address should be mapped 1:1 to the cpu side MMIO address, so that there is no same address allocated from normal system memory. Otherwise it's broken if the same address assigned to the EP for DMA purpose.Fix it to sync with the vendor BSP. Fixes: 568a67e742df ("arm64: dts: rockchip: Fix rk356x PCIe register and range mappings") Fixes: 66b51ea7d70f ("arm64: dts: rockchip: Add rk3568 PCIe2x1 controller") Cc: stable@vger.kernel.org Cc: Andrew Powers-Holmes <aholmes@omnom.net> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/1767600929-195341-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-22arm64: dts: rockchip: Add Anbernic RG-DSChris Morgan2-0/+1238
Add device tree for the Anbernic RG-DS, based on the Rockchip RK3568. All hardware is currently working except for the accelerometer, the speaker output, and one of the two battery gauges. A bug in the Rockchip VOP2 driver is currently causing the device to pause for 30 seconds at boot and is being investigated. The Anbernic RG-DS includes the following (supported) hardware: - 2 640x480 DSI display screens with touch. - 21 buttons. - 2 Analog joysticks. - 3 LEDs (red and green LED share the same housing). - 32GB eMMC, 1 SDMMC slot. - RTL8821CS WiFi/Bluetooth combo - 1 USB 2.0 port in host mode, 1 USB 2.0 port in peripheral mode. - 3.5mm headphone jack with play button support. - 4000mAH battery The following hardware has incomplete driver support and is not yet working: - An Invensense icm42607p accelerometer. - Two Awinic aw87391 speaker amplifiers. - A Cellwise cw2015 battery monitor, which appears to conflict with the rk817 charger driver at the moment. Co-developed-by: Alexander Weinzerl <aweinzerl13@yahoo.com> Signed-off-by: Alexander Weinzerl <aweinzerl13@yahoo.com> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://patch.msgid.link/20260113195721.151205-7-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-22arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576Alexey Charkov2-1/+8
Rockchip RK3576 UFS controller uses a dedicated pin to reset the connected UFS device, which can operate either in a hardware controlled mode or as a GPIO pin. Power-on default is GPIO mode, but the boot ROM reconfigures it to a hardware controlled mode if it uses UFS to load the next boot stage. Given that existing bindings (and rk3576.dtsi) expect a GPIO-controlled device reset, request the required pin config explicitly. The pin is requested with pull-down enabled, which is in line with the SoC power-on default and helps ensure that the attached UFS chip stays in reset until the driver takes over the control of the respective GPIO line. This doesn't appear to affect Linux, but it does affect U-boot: Before: => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ... > => ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2 => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ After: => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ...> => ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2 => md.l 0x2604b398 2604b398: 00000010 00000000 00000000 00000000 ................ (0x2604b398 is the respective pin mux register, with its BIT0 driving the mode of UFS_RST: unset = GPIO, set = hardware controlled UFS_RST) This helps ensure that GPIO-driven device reset actually fires when the system requests it, not when whatever black box magic inside the UFSHC decides to reset the flash chip. Cc: stable@vger.kernel.org Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC") Reported-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://patch.msgid.link/20260121-ufs-rst-v3-1-35839bcb4ca7@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-22arm64: dts: rockchip: Add TPS65185 for PineNoteAndreas Kemnade1-0/+49
As the TPS65185 driver is now upsteram, add it to the PineNote devietrees. This is based on https://ayakael.net/forge/linux-pinenote but modified to the binding requirements. Without any other out-of-tree materials applied, this enables the hwmon temperature reporting and the interrupt counter increments by one per reading. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20260121-rk-tps-v1-1-bc867e1dd200@kemnade.info Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-22riscv: dts: allwinner: d1: Add CPU thermal sensor and zoneAlex Studer3-0/+80
The sun20i THS (built in CPU thermal sensor) is supported in code, but was never added to the device tree. So, add it to the device tree, along with a thermal zone for the CPU. Signed-off-by: Alex Studer <alex@studer.dev> Changes since v1: - Move include before defines in sun20i-d1s.dtsi - Fix register size for thermal-sensor@2009400 - Move thermal-sensor@2009400 in SoC to match register address sorting - Add thermal-zone for sun8i-t113s.dtsi and fix missing cooling-cells Link: https://lore.kernel.org/r/20250218020629.1476126-1-alex@studer.dev Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li> Link: https://patch.msgid.link/20260113182951.1059690-1-lukas.schmid@netcube.li Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-01-22s390/boot/vmlinux.lds.S: Ensure bzImage ends with SecureBoot trailerAlexander Egorenkov1-8/+9
Since commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") the .modinfo section which has SHF_ALLOC ends up in bzImage after the SecureBoot trailer. This breaks SecureBoot because the bootloader can no longer find the SecureBoot trailer with kernel's signature at the expected location in bzImage. To fix the bug, move discarded sections before the ELF_DETAILS macro and discard the .modinfo section which is not needed by the decompressor. Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Cc: stable@vger.kernel.org Suggested-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Tested-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-01-22arm64: Add support for FEAT_{LS64, LS64_V}Yicong Yang5-0/+33
Armv8.7 introduces single-copy atomic 64-byte loads and stores instructions and its variants named under FEAT_{LS64, LS64_V}. These features are identified by ID_AA64ISAR1_EL1.LS64 and the use of such instructions in userspace (EL0) can be trapped. As st64bv (FEAT_LS64_V) and st64bv0 (FEAT_LS64_ACCDATA) can not be tell apart, FEAT_LS64 and FEAT_LS64_ACCDATA which will be supported in later patch will be exported to userspace, FEAT_LS64_V will be enabled only in kernel. In order to support the use of corresponding instructions in userspace: - Make ID_AA64ISAR1_EL1.LS64 visbile to userspace - Add identifying and enabling in the cpufeature list - Expose these support of these features to userspace through HWCAP3 and cpuinfo ld64b/st64b (FEAT_LS64) and st64bv (FEAT_LS64_V) is intended for special memory (device memory) so requires support by the CPU, system and target memory location (device that support these instructions). The HWCAP3_LS64, implies the support of CPU and system (since no identification method from system, so SoC vendors should advertise support in the CPU if system also support them). Otherwise for ld64b/st64b the atomicity may not be guaranteed or a DABT will be generated, so users (probably userspace driver developer) should make sure the target memory (device) also have the support. For st64bv 0xffffffffffffffff will be returned as status result for unsupported memory so user should check it. Document the restrictions along with HWCAP3_LS64. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guestYicong Yang1-0/+6
Using FEAT_{LS64, LS64_V} instructions in a guest is also controlled by HCRX_EL2.{EnALS, EnASR}. Enable it if guest has related feature. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1Yicong Yang1-1/+11
Instructions introduced by FEAT_{LS64, LS64_V} is controlled by HCRX_EL2.{EnALS, EnASR}. Configure all of these to allow usage at EL0/1. This doesn't mean these instructions are always available in EL0/1 if provided. The hypervisor still have the control at runtime. Acked-by: Will Deacon <will@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memoryYicong Yang4-1/+56
If FEAT_LS64WB not supported, FEAT_LS64* instructions only support to access Device/Uncacheable memory, otherwise a data abort for unsupported Exclusive or atomic access (0x35, UAoEF) is generated per spec. It's implementation defined whether the target exception level is routed and is possible to implemented as route to EL2 on a VHE VM according to DDI0487L.b Section C3.2.6 Single-copy atomic 64-byte load/store. If it's implemented as generate the DABT to the final enabled stage (stage-2), inject the UAoEF back to the guest after checking the memslot is valid. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslotsMarc Zyngier1-1/+26
The main use of {LD,ST}64B* is to talk to a device, which is hopefully directly assigned to the guest and requires no additional handling. However, this does not preclude a VMM from exposing a virtual device to the guest, and to allow 64 byte accesses as part of the programming interface. A direct consequence of this is that we need to be able to forward such access to userspace. Given that such a contraption is very unlikely to ever exist, we choose to offer a limited service: userspace gets (as part of a new exit reason) the ESR, the IPA, and that's it. It is fully expected to handle the full semantics of the instructions, deal with ACCDATA, the return values and increment PC. Much fun. A canonical implementation can also simply inject an abort and be done with it. Frankly, don't try to do anything else unless you have time to waste. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: mm: warn once for ioremap attempts on RAM mappingsBreno Leitao1-1/+2
Replace WARN_ON with WARN_ONCE when detecting attempts to ioremap RAM. This prevents log spam when a misbehaving driver repeatedly tries to map RAM via ioremap. A single warning is more than enough to show the broken code path, and extra reports don't add extra information. Warning floods have been seen in production environments where broken external drivers hit this code path thousand of times, causing unnecessary messages to be printed and pressure on the serial console. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: topology: Do not warn on missing AMU in cpuhp_topology_online()Geert Uytterhoeven1-1/+0
When CONFIG_CPUMASK_OFFSTACK is not enabled, and resuming from s2ram on Renesas R-Car H3 (big.LITTLE 4x Cortex-A57 + 4x Cortex-A53), during enabling of the first little core, a warning message is printed: AMU: CPU[4] doesn't support AMU counters This confuses users, as during boot amu_fie_setup() does not print such a message, unless debugging is enabled (freq_counters_valid() prints "CPU%d: counters are not supported.\n" at debug level in that case). Hence drop the warning, freq_counters_valid() has already printed a debug message anyway. Fixes: 6fd9be0b7b2e ("arm64: topology: Handle AMU FIE setup on CPU hotplug") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: Unconditionally enable PAN supportMarc Zyngier5-28/+3
FEAT_PAN has been around since ARMv8.1 (over 11 years ago), has no compiler dependency (we have our own accessors), and is a great security benefit. Drop CONFIG_ARM64_PAN, and make the support unconditionnal. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: Unconditionally enable LSE supportMarc Zyngier7-66/+0
LSE atomics have been in the architecture since ARMv8.1 (released in 2014), and are hopefully supported by all modern toolchains. Drop the optional nature of LSE support in the kernel, and always compile the support in, as this really is very little code. LL/SC still is the default, and the switch to LSE is done dynamically. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22rseq: Implement sys_rseq_slice_yield()Thomas Gleixner16-0/+16
Provide a new syscall which has the only purpose to yield the CPU after the kernel granted a time slice extension. sched_yield() is not suitable for that because it unconditionally schedules, but the end of the time slice extension is not required to schedule when the task was already preempted. This also allows to have a strict check for termination to catch user space invoking random syscalls including sched_yield() from a time slice extension region. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20251215155708.929634896@linutronix.de
2026-01-22arm64/fpsimd: signal: Fix restoration of SVE contextMark Rutland1-6/+16
When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL. (1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time. (2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length. Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear. For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context. Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-01-22arm64/fpsimd: signal: Allocate SSVE storage when restoring ZAMark Rutland1-0/+4
The code to restore a ZA context doesn't attempt to allocate the task's sve_state before setting TIF_SME. Consequently, restoring a ZA context can place a task into an invalid state where TIF_SME is set but the task's sve_state is NULL. In legitimate but uncommon cases where the ZA signal context was NOT created by the kernel in the context of the same task (e.g. if the task is saved/restored with something like CRIU), we have no guarantee that sve_state had been allocated previously. In these cases, userspace can enter streaming mode without trapping while sve_state is NULL, causing a later NULL pointer dereference when the kernel attempts to store the register state: | # ./sigreturn-za | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000046 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x06: level 2 translation fault | Data abort info: | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00 | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000 | Internal error: Oops: 0000000096000046 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : sve_save_state+0x4/0xf0 | lr : fpsimd_save_user_state+0xb0/0x1c0 | sp : ffff80008070bcc0 | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000 | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020 | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0 | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440 | Call trace: | sve_save_state+0x4/0xf0 (P) | fpsimd_thread_switch+0x48/0x198 | __switch_to+0x20/0x1c0 | __schedule+0x36c/0xce0 | schedule+0x34/0x11c | exit_to_user_mode_loop+0x124/0x188 | el0_interrupt+0xc8/0xd8 | __el0_irq_handler_common+0x18/0x24 | el0t_64_irq_handler+0x10/0x1c | el0t_64_irq+0x198/0x19c | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ end trace 0000000000000000 ]--- Fix this by having restore_za_context() ensure that the task's sve_state is allocated, matching what we do when taking an SME trap. Any live SVE/SSVE state (which is restored earlier from a separate signal context) must be preserved, and hence this is not zeroed. Fixes: 39782210eb7e ("arm64/sme: Implement ZA signal handling") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-01-22arm64/fpsimd: ptrace: Fix SVE writes on !SME systemsMark Rutland1-14/+12
When SVE is supported but SME is not supported, a ptrace write to the NT_ARM_SVE regset can place the tracee into an invalid state where (non-streaming) SVE register data is stored in FP_STATE_SVE format but TIF_SVE is clear. This can result in a later warning from fpsimd_restore_current_state(), e.g. WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748 When this happens, fpsimd_restore_current_state() will set TIF_SVE, placing the task into the correct state. This occurs before any other check of TIF_SVE can possibly occur, as other checks of TIF_SVE only happen while the FPSIMD/SVE/SME state is live. Thus, aside from the warning, there is no functional issue. This bug was introduced during rework to error handling in commit: 9f8bf718f2923 ("arm64/fpsimd: ptrace: Gracefully handle errors") ... where the setting of TIF_SVE was moved into a block which is only executed when system_supports_sme() is true. Fix this by removing the system_supports_sme() check. This ensures that TIF_SVE is set for (SVE-formatted) writes to NT_ARM_SVE, at the cost of unconditionally manipulating the tracee's saved svcr value. The manipulation of svcr is benign and inexpensive, and we already do similar elsewhere (e.g. during signal handling), so I don't think it's worth guarding this with system_supports_sme() checks. Aside from the above, there is no functional change. The 'type' argument to sve_set_common() is only set to ARM64_VEC_SME (in ssve_set())) when system_supports_sme(), so the ARM64_VEC_SME case in the switch statement is still unreachable when !system_supports_sme(). When CONFIG_ARM64_SME=n, the only caller of sve_set_common() is sve_set(), and the compiler can constant-fold for the case where type is ARM64_VEC_SVE, removing the logic for other cases. Reported-by: syzbot+d4ab35af21e99d07ce67@syzkaller.appspotmail.com Fixes: 9f8bf718f292 ("arm64/fpsimd: ptrace: Gracefully handle errors") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-01-22Merge tag 'apple-soc-dt-6.20' of ↵Krzysztof Kozlowski28-0/+2317
https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into soc/dt Apple SoC DT update for 6.20 - Add all required nodes and connections for USB3 support. This is responsible for the majority of the diffstat. The dt-bindings for the Type-C PHY are scheduled to be sent via the PHY tree and are already in next. - Add RTC subnodes to the System Management Controller - Add chassis-type property for all M1 and M2 machines - Fix some minor power management issues - Add backlight nodes for the A9X-based iPad Pro * tag 'apple-soc-dt-6.20' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux: arm64: dts: apple: t60xx: Add nodes for integrated USB Type-C ports arm64: dts: apple: t8112: Add nodes for integrated USB Type-C ports arm64: dts: apple: t8103: Add nodes for integrated USB Type-C ports arm64: dts: apple: t8103: Add ps_pmp dependency to ps_gfx arm64: dts: apple: t8103: Mark ATC USB AON domains as always-on arm64: dts: apple: t8112-j473: Keep the HDMI port powered on arm64: dts: apple: Add chassis-type property for Apple iMacs arm64: dts: apple: Add chassis-type property for Mac Pro arm64: dts: apple: Add chassis-type property for Apple desktop devices arm64: dts: apple: Add chassis-type property for all Macbooks arm64: dts: apple: s8001: Add DWI backlight for J98a, J99a arm64: dts: apple: t8103,t60xx,t8112: Add SMC RTC node Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-01-22Merge tag 'lpc32xx-dt-for-6.20' of ↵Krzysztof Kozlowski3-65/+94
https://github.com/vzapolskiy/linux-lpc32xx into soc/dt ARM: nxp: lpc: device tree updates for v6.20 This pull request contains device tree changes for ARM NXP LPC32xx intended for v6.20, please pull the following: - Frank fixes device tree checker warnings reported for NXP LPC32xx boards, - Piotr addes a DMA mux block under SCB, DMA properties to controllers and I2S support for NXP LPC32xx, - Kuldeep corrects values of PrimeCell PL022 'clocks' and 'clock-names' properties, this is the change from a waiting queue, recently it was repeatedly done by Frank, the hesitation was about a probable ABI break, but here in particular the risk is practically negligible due to the kept backwards compatibale 'clocks' property, - Vladimir adds a few missing properties to a number of LPC32xx controllers. * tag 'lpc32xx-dt-for-6.20' of https://github.com/vzapolskiy/linux-lpc32xx: arm: dts: lpc32xx: add interrupts property to Motor Control PWM arm: dts: lpc32xx: add clocks property to Motor Control PWM device tree node ARM: dts: lpc32xx: Add missing properties to I2S device tree nodes ARM: dts: lpc32xx: Declare the second AHB master support on PL080 DMA controller ARM: dts: lpc32xx: Add missing DMA properties ARM: dts: lpc32xx: Use syscon for system control block ARM: dts: lpc32xx: describe FLASH_INT of SLC NAND controller ARM: dts: lpc32xx: change NAND controllers node names ARM: dts: lpc32xx: Update spi clock properties ARM: dts: lpc3250-phy3250: replace deprecated at25 properties with new ones ARM: dts: lpc3250-phy3250: rename nodename at@0 to eeprom@0 ARM: dts: lpc3250-ea3250: add key- prefix for gpio-keys ARM: dts: lpc32xx: remove usb bus and elevate all children nodes Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-01-22Merge tag 'aspeed-6.20-devicetree-1' of ↵Krzysztof Kozlowski7-134/+1812
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/dt aspeed: second batch of arm devicetree changes for 6.20 New platforms: - Facebook Anacapa The Meta Anacapa BMC is the DC-SCM (Data Center Secure Control Module) controller for the Meta OCP Open Rack Wide (ORW) compute tray. This platform is a key component of the AMD Helios AI rack reference design system, designed for next-generation AI workloads. The BMC utilizes the Aspeed AST2600 SoC to manage the compute tray, which contains up to 4 AMD Instinct MI450 Series GPUs (connected via a Broadcom OCP NIC) and host CPUs. Its primary role is to provide essential system control, power sequencing, and telemetry reporting for the compute complex via the OpenBMC software stack. For more detail on the AMD Helios reference design: https://www.amd.com/en/blogs/2025/amd-helios-ai-rack-built-on-metas-2025-ocp-design.html - ASRock Rack ALTRAD8 The ALTRAD8 BMC is an Aspeed AST2500-based BMC for the ASRock Rack ALTRAD8UD-1L2T and ALTRAD8UD2-1L2Q boards. Significant changes: - Switch IBM FSI CFAM nodes to use non-deprecated AT25 properties Updated platforms: - bletchley (Facebook): USB-C tweaks * tag 'aspeed-6.20-devicetree-1' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux: ARM: dts: aspeed: ibm: Use non-deprecated AT25 properties ARM: dts: aspeed: add device tree for ASRock Rack ALTRAD8 BMC dt-bindings: arm: aspeed: add ASRock Rack ALTRAD8 board ARM: dts: aspeed: bletchley: Remove try-power-role from connectors ARM: dts: aspeed: Add Facebook Anacapa platform dt-bindings: arm: aspeed: Add compatible for Facebook Anacapa BMC Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-01-22Merge tag 'nuvoton-arm64-6.20-devicetree-0' of ↵Krzysztof Kozlowski1-0/+1
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/dt Nuvoton arm64 devicetree changes for 6.20 Just the one patch from Rob adding the device_type property to the memory node of the NPCM845 EVB DTS. * tag 'nuvoton-arm64-6.20-devicetree-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux: arm64: dts: nuvoton: Add missing "device_type" property on memory node Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-01-22arm64: dts: marvell: Add SoC specific compatibles to SafeXcel cryptoAngeloGioacchino Del Regno2-2/+4
Following the changes in the binding for the SafeXcel crypto engine, add SoC specific compatibles to the existing nodes in Armada 37xx and CP11x. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2026-01-22KVM: arm64: nv: Return correct RES0 bits for FGT registersZenghui Yu (Huawei)1-1/+1
We had extended the sysreg masking infrastructure to more general registers, instead of restricting it to VNCR-backed registers, since commit a0162020095e ("KVM: arm64: Extend masking facility to arbitrary registers"). Fix kvm_get_sysreg_res0() to reflect this fact. Note that we're sure that we only deal with FGT registers in kvm_get_sysreg_res0(), the if (sr < __VNCR_START__) is actually a never false, which should probably be removed later. Fixes: 69c19e047dfe ("KVM: arm64: Add TCR2_EL2 to the sysreg arrays") Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260121101631.41037-1-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2026-01-22Merge tag 'v6.20-rockchip-dts64-1' of ↵Krzysztof Kozlowski38-25/+2248
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt New boards: Orange Pi CM5 module + Baseboard, Radxa CM5 module + IO-board. PCIe-slot-overlay for rk3576-evb1 New peripherals: some of the video decoders on rk3576 and rk3588 Enabled peripherals: many RK3588-NPUs and a lot of other peripherals on a plethora of boards. * tag 'v6.20-rockchip-dts64-1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (40 commits) arm64: dts: rockchip: Add the vdpu383 Video Decoder on rk3576 arm64: dts: rockchip: Add the vdpu381 Video Decoders on RK3588 arm64: dts: rockchip: Add rk3588s-orangepi-cm5-base device tree dt-bindings: arm: rockchip: Add Orange Pi CM5 Base arm64: dts: rockchip: Enable second HDMI output on CM3588 arm64: dts: rockchip: Add HDMI to Gameforce Ace arm64: dts: rockchip: Enable analog sound on RK3576 EVB1 arm64: dts: rockchip: Enable HDMI sound on RK3576 EVB1 arm64: dts: rockchip: Enable HDMI sound on Luckfox Core3576 arm64: dts: rockchip: Enable HDMI sound on FriendlyElec NanoPi M5 arm64: dts: rockchip: Use a readable audio card name on NanoPi M5 arm64: dts: rockchip: enable NPU on rk3588-jaguar arm64: dts: rockchip: enable NPU on rk3588-tiger dt-bindings: arm: rockchip: fix description for Radxa CM5 dt-bindings: arm: rockchip: fix description for Radxa CM3I arm64: dts: rockchip: Add missing everest,es8388 supplies to rk3399-roc-pc-plus arm64: dts: rockchip: Enable PCIe for ArmSoM Sige1 arm64: dts: rockchip: Enable the NPU on Turing RK1 arm64: dts: rockchip: Enable the NPU on FriendlyElec CM3588 arm64: dts: rockchip: Enable the NPU on NanoPC T6/T6-LTS ... Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-01-22KVM: arm64: Always populate FGT masks at boot timeMarc Zyngier1-9/+9
We currently only populate the FGT masks if the underlying HW does support FEAT_FGT. However, with the addition of the RES1 support for system registers, this results in a lot of noise at boot time, as reported by Nathan. That's because even if FGT isn't supported, we still check for the attribution of the bits to particular features, and not keeping the masks up-to-date leads to (fairly harmess) warnings. Given that we want these checks to be enforced even if the HW doesn't support FGT, enable the generation of FGT masks unconditionally (this is rather cheap anyway). Only the storage of the FGT configuration is avoided, which will save a tiny bit of memory on these machines. Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Fixes: c259d763e6b09 ("KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co") Link: https://lore.kernel.org/r/20260120211558.GA834868@ax162 Link: https://patch.msgid.link/20260122085153.535538-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-22Merge tag 'v6.20-rockchip-dts32-1' of ↵Krzysztof Kozlowski1-1/+16
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt HEVC decoder node for RK3288. * tag 'v6.20-rockchip-dts32-1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: ARM: dts: rockchip: Add vdec node for RK3288 Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-01-22Merge tag 'juno-updates-7.0' of ↵Krzysztof Kozlowski2-4/+11
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/dt Armv8 Juno/Vexpress updates for v7.0 This contains a small set of DT updates: 1. Align DTS node naming with established coding style by replacing underscores with hyphens in node names. This is a safe change and does not affect ABI. 2. Add support for the CMN PMU on the Arm Morello platform, exposing the CMN-Skeena (CMN-600 r3p1–compatible) PMU via the standard CMN-600 binding. This enables PMU access on real Morello SDP hardware, where the registers are functional. * tag 'juno-updates-7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: arm64: dts: arm: Use hyphen in node names arm64: dts: morello: Add CMN PMU Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-01-22ARM: dts: qcom: switch to RPMPD_* indicesDmitry Baryshkov1-2/+2
Use generic RPMPD_* defines for power domain instead of using platform-specific defines. Reviewed-by: Bjorn Andersson <andersson@kernel.org> Acked-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251211-rework-rpmhpd-rpmpd-v2-2-a5ec4028129f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21arm64: dts: qcom: sm6115: Add CX_MEM/DBGC GPU regionsKonrad Dybcio1-2/+6
Describe the GPU register regions, with the former existing but not being used much if at all on this silicon, and the latter containing various debugging levers generally related to dumping the state of the IP upon a crash. Fixes: 11750af256f8 ("arm64: dts: qcom: sm6115: Add GPU nodes") Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Closes: https://lore.kernel.org/linux-arm-msm/8a64f70b-8034-45e7-86a3-0015cf357132@oss.qualcomm.com/T/#m404f1425c36b61467760f058b696b8910340a063 Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251229-topic-6115_2290_gpu_dbgc-v1-3-4a24d196389c@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21arm64: dts: qcom: agatti: Add CX_MEM/DBGC GPU regionsKonrad Dybcio1-2/+6
Describe the GPU register regions, with the former existing but not being used much if at all on this silicon, and the latter containing various debugging levers generally related to dumping the state of the IP upon a crash. Fixes: 4faeef52c8e6 ("arm64: dts: qcom: qcm2290: Add GPU nodes") Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Closes: https://lore.kernel.org/linux-arm-msm/8a64f70b-8034-45e7-86a3-0015cf357132@oss.qualcomm.com/T/#m404f1425c36b61467760f058b696b8910340a063 Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251229-topic-6115_2290_gpu_dbgc-v1-2-4a24d196389c@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21arm64: dts: qcom: sm8750: add ADSP fastrpc-compute-cb nodesAlexey Klimov1-0/+61
Add ADSP fastrpc nodes for sm8750 SoC. Cc: Ekansh Gupta <quic_ekangupt@quicinc.com> Cc: Srinivas Kandagatla <srini@kernel.org> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Link: https://lore.kernel.org/r/20251209-sm8750-fastrpc-adsp-v3-2-ccfff49a8af9@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21arm64: dts: qcom: sm8750: add memory node for adsp fastrpcAlexey Klimov1-0/+8
Add optional memory heap node that can be used for ADSP fastrpc. Cc: Ekansh Gupta <quic_ekangupt@quicinc.com> Cc: Srinivas Kandagatla <srini@kernel.org> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Link: https://lore.kernel.org/r/20251209-sm8750-fastrpc-adsp-v3-1-ccfff49a8af9@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21arm64: dts: qcom: switch to RPMPD_* indicesDmitry Baryshkov8-40/+40
Use generic RPMPD_* defines for power domain instead of using platform-specific defines. Reviewed-by: Bjorn Andersson <andersson@kernel.org> Acked-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251211-rework-rpmhpd-rpmpd-v2-1-a5ec4028129f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21Merge tag 'soc-fixes-6.19-2' of ↵Linus Torvalds21-60/+39
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "The main changes are devicetree updates for qualcomm and rockchips arm64 platforms, fixing minor mistakes in SoC and board specific settings: - GPIO settings for Pinephone Pro buttons - Register ranges for rk3576 GPU - Power domains on sc8280xp - Clocks on qcom talos - dtc warnings for extraneous properties, nonstandard node names and undocument identifiers The Tegra210 platform gets a single revert for a devicetree change that caused a 6.19 regression. On 32-bit Arm, we have trivial fixes for Microchip SAMA7 devicetree files and NPCM Kconfig, as well as Andrew Jeffery being officially listed as MAINTAINER for NPCM. A single driver fix is for Qualcomm RPMHD power domains, bringing the driver up to date with a devicetree change that added additional power domains to be enabled" * tag 'soc-fixes-6.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (27 commits) MAINTAINERS: Add Andrew as M: to ARM/NUVOTON NPCM ARCHITECTURE MAINTAINERS: update email address for Yixun Lan Revert "arm64: tegra: Add interconnect properties for Tegra210" arm64: dts: rockchip: Drop unsupported properties arm64: dts: rockchip: Fix gpio pinctrl node names arm64: dts: rockchip: Fix pinctrl property typo on rk3326-odroid-go3 arm64: dts: rockchip: Drop "sitronix,st7789v" fallback compatible from rk3568-wolfvision ARM: dts: microchip: sama7d65: fix size-cells property for i2c3 ARM: dts: microchip: sama7d65: fix the ranges property for flx9 arm: npcm: drop unused Kconfig ERRATA symbol arm64: dts: rockchip: Fix wrong register range of rk3576 gpu arm64: dts: rockchip: Configure MCLK for analog sound on NanoPi M5 arm64: dts: rockchip: Fix headphones widget name on NanoPi M5 ARM: dts: microchip: lan966x: Fix the access to the PHYs for pcb8290 arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s arm64: dts: rockchip: remove dangerous max-link-speed from helios64 arm64: dts: rockchip: fix unit-address for RK3588 NPU's core1 and core2's IOMMU arm64: dts: rockchip: Fix wifi interrupts flag on Sakura Pi RK3308B arm64: dts: qcom: sm8650: Fix compile warnings in USB controller node arm64: dts: qcom: sm8550: Fix compile warnings in USB controller node ...
2026-01-21arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: enable SDIO interfaceNick Xie1-0/+27
Enable the SDIO controller interface connected to the on-board AP6256 WiFi/BT module. Signed-off-by: Nick Xie <nick@khadas.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260121014725.122722-1-nick@khadas.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-01-21perf/x86/intel: Do not enable BTS for guestsFernand Sieber1-2/+11
By default when users program perf to sample branch instructions (PERF_COUNT_HW_BRANCH_INSTRUCTIONS) with a sample period of 1, perf interprets this as a special case and enables BTS (Branch Trace Store) as an optimization to avoid taking an interrupt on every branch. Since BTS doesn't virtualize, this optimization doesn't make sense when the request originates from a guest. Add an additional check that prevents this optimization for virtualized events (exclude_host). Reported-by: Jan H. Schönherr <jschoenh@amazon.de> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Fernand Sieber <sieberf@amazon.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20251211183604.868641-1-sieberf@amazon.com
2026-01-21arm64: dts: qcom: oneplus-enchilada: Specify i2c4 clock frequencyDavid Heidelberg1-0/+2
Per the binding, omitting the clock frequency from a Geni I2C controller node defaults the bus to 100 kHz. But at least in Linux, a friendly info print highlights the lack of explicitly defined frequency in the DeviceTree. Specify the frequency, to give it an explicit value, and to silence the log print in Linux. Downstream doesn't define any frequency, thus also using 100 kHz. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://lore.kernel.org/r/20251130-enchilada-i2c-freq-v1-1-2932480a0261@ixit.cz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21arm64: dts: qcom: sm6350: Add clocks for aggre1 & aggre2 NoCLuca Weiss1-0/+3
As per updated bindings, add the clocks for those two interconnects, which are required to set up QoS correctly. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20251114-sm6350-icc-qos-v2-5-6af348cb9c69@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21arm64: dts: qcom: agatti: enable FastRPC on the ADSPDmitry Baryshkov1-0/+41
On Agatti platform the ADSP provides FastRPC support. Add corresponding device node, in order to be able to utilize the DSP offload from the Linux side. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260113-agatti-fastrpc-v2-1-b66870213f89@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-21Merge tag 'qcom-arm64-fixes-for-6.19' of ↵Arnd Bergmann5-13/+16
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm Arm64 DeviceTree fixes for v6.19 Add missing power-domains to the SC8280XP RPM power-domain and ensure these are voted for from the remoteproc instances while powering them up. Clear a couple of DeviceTree validation warnings in SM8550 and SM8650 USB controller nodes. Specify the correct display panel on the OnePlus 6. Correct the UFS clock mapping on Talos, to ensure UFS is properly clocked. Add Abel's old emails address to .mailmap. * tag 'qcom-arm64-fixes-for-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: dts: qcom: sm8650: Fix compile warnings in USB controller node arm64: dts: qcom: sm8550: Fix compile warnings in USB controller node arm64: dts: qcom: sc8280xp: Add missing VDD_MXC links pmdomain: qcom: rpmhpd: Add MXC to SC8280XP dt-bindings: power: qcom,rpmpd: Add SC8280XP_MXC_AO arm64: dts qcom: sdm845-oneplus-enchilada: Specify panel name within the compatible mailmap: Update email address for Abel Vesa arm64: dts: qcom: talos: Correct UFS clocks ordering Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-21kallsyms/bpf: rename __bpf_address_lookup() to bpf_address_lookup()Petr Mladek3-3/+3
bpf_address_lookup() has been used only in kallsyms_lookup_buildid(). It was supposed to set @modname and @modbuildid when the symbol was in a module. But it always just cleared @modname because BPF symbols were never in a module. And it did not clear @modbuildid because the pointer was not passed. The wrapper is no longer needed. Both @modname and @modbuildid are now always initialized to NULL in kallsyms_lookup_buildid(). Remove the wrapper and rename __bpf_address_lookup() to bpf_address_lookup() because this variant is used everywhere. [akpm@linux-foundation.org: fix loongarch] Link: https://lkml.kernel.org/r/20251128135920.217303-6-pmladek@suse.com Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Petr Mladek <pmladek@suse.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Cc: Aaron Tomlin <atomlin@atomlin.com> Cc: Daniel Borkman <daniel@iogearbox.net> Cc: Daniel Gomez <da.gomez@samsung.com> Cc: John Fastabend <john.fastabend@gmail.com> Cc: Kees Cook <kees@kernel.org> Cc: Luis Chamberalin <mcgrof@kernel.org> Cc: Marc Rutland <mark.rutland@arm.com> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Petr Pavlu <petr.pavlu@suse.com> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-21watchdog: softlockup: panic when lockup duration exceeds N thresholdsLi RongQing4-4/+4
The softlockup_panic sysctl is currently a binary option: panic immediately or never panic on soft lockups. Panicking on any soft lockup, regardless of duration, can be overly aggressive for brief stalls that may be caused by legitimate operations. Conversely, never panicking may allow severe system hangs to persist undetected. Extend softlockup_panic to accept an integer threshold, allowing the kernel to panic only when the normalized lockup duration exceeds N watchdog threshold periods. This provides finer-grained control to distinguish between transient delays and persistent system failures. The accepted values are: - 0: Don't panic (unchanged) - 1: Panic when duration >= 1 * threshold (20s default, original behavior) - N > 1: Panic when duration >= N * threshold (e.g., 2 = 40s, 3 = 60s.) The original behavior is preserved for values 0 and 1, maintaining full backward compatibility while allowing systems to tolerate brief lockups while still catching severe, persistent hangs. [lirongqing@baidu.com: v2] Link: https://lkml.kernel.org/r/20251218074300.4080-1-lirongqing@baidu.com Link: https://lkml.kernel.org/r/20251216074521.2796-1-lirongqing@baidu.com Signed-off-by: Li RongQing <lirongqing@baidu.com> Cc: Eduard Zingerman <eddyz87@gmail.com> Cc: Hao Luo <haoluo@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Fastabend <john.fastabend@gmail.com> Cc: KP Singh <kpsingh@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Martin KaFai Lau <martin.lau@linux.dev> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Song Liu <song@kernel.org> Cc: Stanislav Fomichev <sdf@fomichev.me> Cc: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-21kernel.h: drop hex.h and update all hex.h usersRandy Dunlap7-0/+7
Remove <linux/hex.h> from <linux/kernel.h> and update all users/callers of hex.h interfaces to directly #include <linux/hex.h> as part of the process of putting kernel.h on a diet. Removing hex.h from kernel.h means that 36K C source files don't have to pay the price of parsing hex.h for the roughly 120 C source files that need it. This change has been build-tested with allmodconfig on most ARCHes. Also, all users/callers of <linux/hex.h> in the entire source tree have been updated if needed (if not already #included). Link: https://lkml.kernel.org/r/20251215005206.2362276-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Yury Norov (NVIDIA) <yury.norov@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-21lib/tests: convert test_uuid module to KUnitRyota Sakamoto13-13/+0
Move lib/test_uuid.c to lib/tests/uuid_kunit.c and convert it to use KUnit. This change switches the ad-hoc test code to standard KUnit test cases. The test data remains the same, but the verification logic is updated to use KUNIT_EXPECT_* macros. Also remove CONFIG_TEST_UUID from arch/*/configs/* because it is no longer used. The new CONFIG_UUID_KUNIT_TEST will be automatically enabled by CONFIG_KUNIT_ALL_TESTS. [lukas.bulwahn@redhat.com: MAINTAINERS: adjust file entry in UUID HELPERS] Link: https://lkml.kernel.org/r/20251217053907.2778515-1-lukas.bulwahn@redhat.com Link: https://lkml.kernel.org/r/20251215134322.12949-1-sakamo.ryota@gmail.com Signed-off-by: Ryota Sakamoto <sakamo.ryota@gmail.com> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: David Gow <davidgow@google.com> Cc: Andriy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: Lukas Bulwahn <lukas.bulwahn@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-24 00:23:44 +0300