summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-08-02arm64: dts: qcom: sm6375: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-18-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: sm6350: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-17-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: sc7180: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-16-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: sm8350: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-15-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: sc7280: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-14-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: sm8550: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-12-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: qdu1000: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-11-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: qcs8300: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-10-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: sa8775p: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-9-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: sm8450: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-8-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: kaanapali: Add minidump SRAM config to SCM nodeMukesh Ojha1-0/+5
Point the SCM node at the minidump config slot in the always-on SRAM. Boot firmware reads this word before DDR is initialised on a warm reset to decide where to deliver the minidump. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-7-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02arm64: dts: qcom: glymur: Add Asus Zenbook A16 (UX3607OA)Konrad Dybcio4-2/+1272
UX3607OA is a variant of the Asus Zenbook A16 built on the Qualcomm Glymur platform. It comes with an 18-core X2 Elite Extreme SoC, 48GiB of RAM, NVMe storage, a 2880 x 1800 OLED screen, and the other typical Glymur platform capabilities. The hardware wiring is very different versus the 14" SKU - the larger one is based on the System-In-Package reference design, unlike the smaller one, which derives from a more common Chip-On-Board base. Currently working: - Audio playback (4 speakers) - GPU, Display - HDMI port - Keyboard, touchpad, lid switch - Privacy LEDs (camera-use, camera-block, mic-mute) - Charging, Type-C, Type-A port - Onboard SD Card slot (RTS5329) - Wi-Fi, Bluetooth (QCC2072) - Touchscreen should work on the SKUs that have it, but it remains untested due to lack of access to such a device Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-topic-a16_submission-v1-2-8ea213130d05@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-02Merge tag 'riscv-for-linus-7.2-rc6' of ↵Linus Torvalds5-15/+20
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: - Fix swiotlb initialization on systems where DRAM is located above 4GiB (such as the Tenstorrent Blackhole cards) - Fix an out-of-bounds access in the memory hot-remove code that can occur on Sv39 and Sv48 systems - Avoid oopsing during boot if the SBI component of the unaligned access performance checking code loses a race against __init function freeing - Avoid attempting to install the debug-enabled vDSO when it shouldn't be built due to !CONFIG_MMU - Avoid some sparse warnings by adding missing __iomem notations in get_cycles{,_hi}() - Drop an unnecessary runtime warning in the SiFive errata handler * tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: vdso: Only try to install vDSO when present riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove riscv: drop __init from vec_check_unaligned_access_speed_all_cpus riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB riscv/sifive: remove warning in errata riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi()
2026-08-02arm64: dts: rockchip: Add LincStation E1Samuel Holland2-0/+1001
LincStation E1 is an entry-level NAS device powered by the RK3568B2 SoC with two 3.5" HDD slots (behind a SATA port multiplier) and two m.2 2280 slots for SSDs (each PCIe 3.0 x1). Other major features include: - 4 GiB DRAM / 64 GB eMMC - RTL8125 2.5 Gb Ethernet - Fn-Link 6222B-SRC Wi-Fi 5 / Bluetooth module - 1 USB 5 Gbps + 2 USB high speed ports - HDMI output Each HDD slot provides a GPIO input for disk presence detection and an output for power control. Since the disks are behind a port multiplier, there is no way to describe them in the devicetree, so the disk power is enabled at all times by GPIO hogs, and the detection inputs are used only as LED triggers. The board contains several pairs of amber/white LEDs for power, disk, m.2 slot, and network status. These are configured to use triggers when possible. The PWM fan uses a relatively aggressive fan curve to keep the hard disks within a safe temperature range. It may benefit from further tuning. The pinhole reset button is multiplexed between the SoC reset pin and an ADC input. The mux is configured here to drive the SoC reset pin, as this works reliably without polling by software. The adc-keys description is included for use by a devicetree overlay if desired. Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://patch.msgid.link/20260711192842.845048-5-samuel@sholland.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-08-02Merge tag 's390-7.2-6' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 updates from Vasily Gorbik: - Fix PCI MMIO write syscall falsely reporting success for mappings not valid for MMIO when MIO is unavailable by returning -EFAULT - Fix CPRB parameter buffer overflows in zcrypt CCA AES cipher and ECC private key conversion by rejecting oversized key tokens - Fix buffer overreads and length underflow in pkey and zcrypt CCA token validation by checking length fields against actual buffer sizes - Fix out of bounds permission bitmap access in zcrypt EP11 admin CPRB filtering on custom device nodes by using AP_DOMAINS as the limit - Fix speculative permission bitmap reads in zcrypt CCA and EP11 admin CPRB handling by sanitizing user controlled domain indexes - Fix sensitive key material left in zcrypt CCA clear key import buffers by scrubbing CPRB and temporary buffers after use * tag 's390-7.2-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() s390/zcrypt: Close speculative mem read possibility s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs s390/zcrypt: Fix buffer over-read in cca_cipher2protkey s390/zcrypt: Validate length for CCA ECC private key requests s390/zcrypt: Validate length for CCA AES cipher key requests s390/pci: Fix s390_pci_mmio_write syscall error return without MIO
2026-08-02arm64: dts: rockchip: Add Vicharak Vaaman boardHrushiraj Gandhi2-0/+459
Add initial devicetree support for the Vicharak Vaaman, an RK3399-based single-board computer. Supported peripherals: - RK808 PMIC with core/logic/IO regulators - SYR827/SYR828 (vdd_cpu_b/vdd_gpu) CPU-big and GPU regulators - Mali GPU - Gigabit Ethernet (RGMII, RTL8211E PHY via &gmac with mdio subnode) - eMMC (HS400, enhanced strobe) - microSD card slot - SARADC and TSADC - PWM-based vdd_log regulator - UART2 serial console Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com> Link: https://patch.msgid.link/20260730045947.388660-3-hrushirajg23@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-08-02Merge tag 'x86-urgent-2026-08-02' of ↵Linus Torvalds2-3/+12
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull misc x86 fixes from Ingo Molnar: - Fix the boot-time memcmp() asm implementation's constraints and optimization properties (Mauricio Faria de Oliveira) - Move the 0xd0...0xd7 AMD Zen5 model range from the Zen6 range where it mistakenly ended up (Pratik Vishwakarma) * tag 'x86-urgent-2026-08-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/CPU/AMD: Carve out a Zen5 models range x86/boot: Add volatile, clobbers and zero-length test in memcmp()
2026-08-02arm64: dts: rockchip: Add icm42607p IMU for RG-DSChris Morgan1-1/+7
Add the Invensense ICM42607P IMU for the Anbernic RG-DS. Mount-matrix was tested with iio-sensor-proxy and reports correct orientation. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://patch.msgid.link/20260728225542.174825-10-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-08-02arm64: dts: rockchip: Correct white-space styleKrzysztof Kozlowski4-4/+4
Correct a few white-space issues, like missing space before bracket '{' character or spurious space, which will be flagged by dt-check-style ("redundant-whitespace" warning). No functional changes. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801210247.383632-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-08-02ARM: dts: rockchip: Correct white-space styleKrzysztof Kozlowski7-7/+7
Correct a few white-space issues, like missing space before bracket '{' character or spurious space, which will be flagged by dt-check-style ("redundant-whitespace" warning). No functional changes. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801210247.383632-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-08-02arm64: Add override for MMFR1.HAFDBSRobin Murphy1-0/+2
In general it might be nice to have the ability to disable hardware access/dirty bit management for debugging or performance comparison purposes without having to rebuild the kernel. However once FEAT_HAFT comes into the picture we also start to have a real functional concern where the decision to use HAFT based on the boot CPUs can prevent SVA or late-onlining if SMMUs/CPUs are later found to lack HAFT support. To that end, add the appropriate MMFR1 override, with an easy "nohaft" alias for the significant case, partly since the feature/field naming isn't the most obvious, but also so it could potentially be redirected in future if someone wanted to attempt a higher-level means of turning off just HAFT usage independently from FEAT_HDBSS. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm64: syscall: Pass 'orig_x0' as first argument to native system callWill Deacon1-4/+9
syscall_get_arguments() returns 'regs->orig_x0' for the first system call argument so as to avoid aliasing with the syscall return value in 'regs->regs[0]' on the return path, however the actual syscall invocation passes 'regs->regs[0]' as the first parameter. Although the two registers should be kept in sync during syscall entry for native tasks, pass 'regs->orig_x0' as the first syscall parameter for consistency with the syscall argument APIs. Compat tasks continue to use 'regs->regs[0]' for compatibility with the behaviour of the 32-bit kernel. Suggested-by: Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entryWill Deacon1-0/+50
Commit e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") attempted to resolve a long-standing issue with syscall entry tracing, where a tracer is able to manipulate the first syscall argument without being subjected to seccomp or audit checking. Unfortunately, that fix was incomplete [1], as it failed to update 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated. Rather than add hooks to the core seccomp code, instead move the synchronisation code into the ptrace GPR and syscall setting code so that 'orig_x0' is kept up to date with x0 whenever we're stopped on the syscall entry path. Cc: Kees Cook <kees@kernel.org> Cc: Jinjie Ruan <ruanjinjie@huawei.com> Cc: Mark Rutland <mark.rutland@arm.com> Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org [1] Reported-by: Yiqi Sun <sunyiqixm@gmail.com> Link: https://lore.kernel.org/all/20260529065444.1336608-1-sunyiqixm@gmail.com/ Fixes: e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") Fixes: a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") Tested-by: Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm64/fpsimd: ptrace: Fix inactive SVE and SSVE regsetsKarl Mehltretter1-2/+2
sve_init_header_from_task() takes header as a pointer, so for the inactive mode header->size = sizeof(header); stores 8 rather than sizeof(struct user_sve_header), which is 16. Userspace sees an impossible size smaller than the header it describes. The inactive-mode check in sve_get_common() compares header.size against sizeof(header) as well, but there header is a struct, so the check can never fire. Reads of NT_ARM_SVE and NT_ARM_SSVE for the inactive mode therefore still return the other mode's FPSIMD data, exactly the situation the check was added to prevent. Fix the size, and make the check return the remaining membuf space instead of 0, which regset_get() would interpret as the entire (zero-filled) buffer having been populated. Fixes: b93e685ecff7 ("arm64/fpsimd: ptrace: Do not present register data for inactive mode") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm64: smp: Fix IPI teardown for GICv5 flowVladimir Murzin1-1/+1
Sashiko reported that during CPU offlining, __cpu_disable() is executed by the stopper thread via take_cpu_down() with local interrupts disabled. __cpu_disable() calls ipi_teardown(), which invokes ipi_lpi_disable(). For the GICv5 flow, this eventually calls the sleepable disable_irq(). This can be reproduced easily with CONFIG_DEBUG_ATOMIC_SLEEP=y by offlining a CPU: BUG: sleeping function called from invalid context at kernel/irq/manage.c:702 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 20, name: migration/1 preempt_count: 1, expected: 0 no locks held by migration/1/20. irq event stamp: 186 hardirqs last enabled at (185): [<ffff800080b084c8>] _raw_spin_unlock_irq+0x38/0x68 hardirqs last disabled at (186): [<ffff8000801f8e08>] multi_cpu_stop+0xc8/0x190 softirqs last enabled at (80): [<ffff8000800c48b8>] handle_softirqs+0x410/0x468 softirqs last disabled at (75): [<ffff8000800102f4>] __do_softirq+0x1c/0x28 Fix this by using disable_irq_nosync() instead, which is safe in this atomic context. Fixes: ba1004f861d1 ("arm64: smp: Support non-SGIs for IPIs") Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm64: escalate smp_send_stop() to an SDEI NMI as a last resortKiryl Shutsemau (Meta)2-35/+96
A CPU wedged with interrupts masked ignores the stop IPI, and without pseudo-NMI there is no NMI IPI to escalate to: a reboot proceeds with the CPU still running, and a kdump misses its registers. Add a third rung to smp_send_stop(): once the IPI (and pseudo-NMI IPI, if enabled) rungs have run, signal SDEI event 0 at whatever stayed online. Firmware delivers it regardless of the target's DAIF, so it reaches a CPU a plain IPI cannot; the target acks by going offline, which the caller already polls for. Fold the stop bookkeeping into one arm64_nmi_cpu_stop(regs, die_on_crash), shared by the stop IPI handlers, panic_smp_self_stop() and the SDEI handler, replacing the near-duplicate local_cpu_stop() and ipi_cpu_crash_stop(). @die_on_crash is the only difference: the IPI handlers pass true and PSCI CPU_OFF the CPU on a crash stop so a capture kernel can reclaim it; the SDEI handler and self-stop pass false and park. The SDEI park is required, not conservative -- its handler runs inside an SDEI event that is never completed (completing it resumes the wedged context), and a CPU_OFF from that unfinished-event context wedges EL3 on some firmware (left as a follow-up). The dump is unaffected; only re-onlining the CPU in an SMP capture kernel is lost. Suggested-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02drivers/firmware: add SDEI cross-CPU NMI service for arm64Kiryl Shutsemau (Meta)2-0/+35
Deliver an NMI-like event to an interrupt-masked arm64 CPU via the standard SDEI software-signalled event (event 0), without the pseudo-NMI hot-path cost: register a handler for event 0 and poke a target with sdei_event_signal(0, mpidr). First user is arch_trigger_cpumask_backtrace() (sysrq-l, RCU stalls, hung-task/soft-lockup dumps), which otherwise rides an IPI that can't reach a masked CPU. Falls back to the IPI path when SDEI is absent; no watchdog backend yet, so the stock detector is untouched. Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Yin Fengwei <fengwei_yin@linux.alibaba.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm64: cpucaps: Remove stale comment about keeping capabilities sortedWill Deacon1-1/+1
There is no functional requirement to keep the entries in arm64's tools/cpucaps file sorted alphabetically and, in fact, they have fallen out of order over time. Given that only the arm64 tree touches this file and the perceived benefit of sorting was to help with conflicts, just remove the stale comment and accept that we're collectively not very good at the alphabet. In the limited cases where a specific ordering is important, we enforce it through build-time assertions (e.g. in can_use_gic_priorities()). Cc: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> Reported-by: Marc Zyngier <maz@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-02arm64: mm: Treat all devices as dma-coherent when CLIDR_EL1.LoC == 0Will Deacon1-0/+5
On systems where CLIDR_EL1.LoC == 0, no cache maintenance is required when cleaning or invalidating to the Point of Coherency and therefore all DMA agents can be treated as coherent. Extend arch_setup_dma_ops() to take CLIDR_EL1.LoC into account when setting the DMA ops for a device, emitting a warning message if the firmware advertises a non-coherent device on a fully coherent system. Cc: Steffen Eiden <seiden@linux.ibm.com> Cc: Andreas Grapentin <gra@linux.ibm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-08-01Merge patch series "Initial Apple M3 Pro, Max and Ultra device trees"Sven Peter19-0/+5767
Janne Grunau <j@jannau.net> says: This series adds device trees for Apple silicon devices with M3 Pro, Max and Ultra SoCs. The M3 generation has fewer devices than their M1 and M2 predecessors. The only non-laptop device is the M3 Ultra Mac Studio. The Laptops are the known 14 and 16-inch Macbook Pros now with M3 Pro and M3 Max SoCs. The M3 Max variant with fewer CPU and GPU cores has additionally only a 384-bit wide memory bus instead of 512-bit of the full M3 Max. It has a separate identifier (T6034) and so there are six laptop device trees. Another difference to M1 and M2 Pro/Max/Ultra is that the M3 Pro is distinct SoC design and not a smaller M3 Max. For this reason both M3 Max variants and the M3 Ultra will use "apple,t6030" as compatible prefix. In the M1 and M2 generations Pro, Max and Ultra SoCs shared "apple,t6000" / "apple,t6020" as common prefix. There is currently no known difference but M3 Pro and M3 Max are not as closely related as previously. This series adds the same level of hardware as the base M3 (T8122) has in v7.2-rc1. This includes CPU cores, interrupt controller, power states, watchdog, serial, pin controller, i2c and the boot framebuffer. This is intended as base so that support for additional hardware can be added to all M3 based devices at the same time. Link: https://patch.msgid.link/20260724-apple-t603x-initial-devices-v3-0-bbeba0420603@jannau.net Signed-off-by: Sven Peter <sven@kernel.org>
2026-08-01arm64: dts: apple: Initial T6030 (M3 Pro) device treesJanne Grunau5-0/+2007
Minimal device trees for the M3 Pro based 14-inch and 16-inch MacBook Pro released in November 2023. The M3 Pro is a distinct SoC design and not a cut down version of the Max variant like for M1 and M2 Pro. The M3 Pro has only a single cluster with up to 6 performance cores and one cluster with 6 efficiency cores. While it no longer shares a common SoC .dtsi the devices itself are still similar to the ones with M3 Max. It is still useful to share the basic device composition in t603x-j514-j516.dtsi. For the M3 Pro based devices additional overrides for diverging pin and irq numbers are expected. The device trees have devices nodes for CPU cores, timer, interrupt controller, power states, watchdog, serial, pin controller, i2c, PWM based keyboard LED illumination and the boot framebuffer. Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Sven Peter <sven@kernel.org>
2026-08-01arm64: dts: apple: Initial T603[124] (M3 Max and Ultra) device treesJanne Grunau15-0/+3760
Contains minimal device trees for all M3 Max and Ultra Apple silicon devices. Those are 14-inch and 16-inch MacBook Pros with M3 Max released in November 2023 and Mac Studio with M3 Ultra released in 2025. This does not include M3 Pro since it is separate SoC and not a smaller variant of the M3 Max contrary to the M1 and M2 generations. The smaller M3 Max variant (10 performance cores) has its own chip variant (T6034) but is clearly the same design as T6031. Besides fewer CPU performance cores and GPU cores it misses also on fourth of the memory controllers and thus has an aggregated bus width of 384 bit instead of 512 bit. Both M3 Ultra variants (28 or 32 CPU cores) are based on T6031 judging by the advertised memory bandwidth of 819GB/s. This uses the same multi-die macros as t600x*.dtsi and t602x.dtsi to support M3 Max and M3 Ultra without duplicating device nodes. Since the M3 Pro can't use the same .dtsi files "t6031*.dtsi" are used to define common nodes for T6031, T6032 and T6034. The device trees have devices nodes for CPU cores, timer, interrupt controller, power states, watchdog, serial, pin controller, i2c, PWM based keyboard LED illumination and the boot framebuffer. Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Sven Peter <sven@kernel.org>
2026-08-01arm64: dts: fsd: Align continued properties and add missing blank linesKrzysztof Kozlowski2-44/+55
Trivial white-space only changes to adjust to DTS coding style and fix dt-check-style strict warnings like: [required-blank-lines] child node must be preceded by a blank line [continuation-alignment] continuation should align to column 39 (under < or ") Reviewed-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-dts-coding-style-strict-v2-8-f09a659ab80d@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-08-01arm64: dts: fsd: Move 'status' to the end to match coding styleKrzysztof Kozlowski2-2/+28
'status' property is special, thus DTS coding style expects it to be always the last property preceded with a blank line, as reported by dt-check-style: [required-blank-lines] "status" must be preceded by a blank line [property-order] property 'phy-mode' out of canonical order (should sort before 'status') Reviewed-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-dts-coding-style-strict-v2-7-f09a659ab80d@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-08-01arm64: dts: google: Align continued properties and add missing blank linesKrzysztof Kozlowski1-3/+8
Trivial white-space only changes to adjust to DTS coding style and fix dt-check-style strict warnings like: [required-blank-lines] child node must be preceded by a blank line [continuation-alignment] continuation should align to column 39 (under < or ") Reviewed-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-dts-coding-style-strict-v2-6-f09a659ab80d@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-08-01arm64: dts: google: Move 'status' to the end to match coding styleKrzysztof Kozlowski4-1/+85
'status' property is special, thus DTS coding style expects it to be always the last property preceded with a blank line, as reported by dt-check-style: [required-blank-lines] "status" must be preceded by a blank line [property-order] property 'vcc-supply' out of canonical order (should sort before 'status') Reviewed-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-dts-coding-style-strict-v2-5-f09a659ab80d@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-08-01arm64: dts: exynos: Re-order clocks and align continued propertiesKrzysztof Kozlowski1-141/+141
Trivial white-space only changes to adjust to DTS coding style (clocks-names should follow clocks) and fix dt-check-style strict warnings like: [property-order] property 'clocks' out of canonical order (should sort before 'clock-names') [continuation-alignment] continuation should align to column 39 (under < or ") Reviewed-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-dts-coding-style-strict-v2-4-f09a659ab80d@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-08-01arm64: dts: exynos5433: Override thermal zones by phandleKrzysztof Kozlowski2-3/+4
Fix indentation of DTSI file with thermal zones (two opening { brackets, but only one indent) by using a safer choice of phandle/label override. Reviewed-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-dts-coding-style-strict-v2-3-f09a659ab80d@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-08-01arm64: dts: exynos: Align continued properties and add missing blank linesKrzysztof Kozlowski19-188/+359
Trivial white-space only changes to adjust to DTS coding style and fix dt-check-style strict warnings like: [required-blank-lines] child node must be preceded by a blank line [continuation-alignment] continuation should align to column 39 (under < or ") Reviewed-by: André Draszik <andre.draszik@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-dts-coding-style-strict-v2-2-f09a659ab80d@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-08-01arm64: dts: exynos: Move 'status' to the end to match coding styleKrzysztof Kozlowski21-24/+485
'status' property is special, thus DTS coding style expects it to be always the last property preceded with a blank line, as reported by dt-check-style: [property-order] property 'iommus' out of canonical order (should sort before 'status') [required-blank-lines] "status" must be preceded by a blank line Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-b4-dts-coding-style-strict-v2-1-f09a659ab80d@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-08-01KVM: riscv: Fix infinite loop in NACL hfence entry allocationZongmin Zhou1-1/+1
try_count is initialized to 5 but never decremented in the retry path, making the `if (try_count)` check always true. If all NACL shared memory hfence entries remain in the pending state after sync, the function loops forever, causing a soft lockup. Decrement try_count on each retry so the fallback warning and return become reachable. Fixes: d466c19cead5 ("RISC-V: KVM: Add common nested acceleration support") Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260716073756.44153-1-min_halo@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-01RISC-V: KVM: Account VM-scoped allocations to the VM cgroupYuhang.chen6-9/+10
Charge the per-VM and per-vCPU allocations (stage-2 PGD, APLIC state, IMSIC context, vector context, FWFT config, PMU snapshot) to the allocating process's memory cgroup via GFP_KERNEL_ACCOUNT / __GFP_ACCOUNT. Per-CPU module-init allocations and transient scratch buffers are left unaccounted. Measured results (KVM guest run in a memory cgroup; VM cgroup memory.current after guest boot): VM cgroup memory.current 1044480 bytes Assisted-by: YuanSheng:deepseek-v4-pro Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn> Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn> Signed-off-by: Yuhang.chen <yhchen312@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260716064112.2387938-1-yhchen312@gmail.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-01RISC-V: KVM: Introduce make_xfence_request_nodata for FENCE.I requestsWang Yechao1-7/+27
FENCE.I does not need hfence data, but it currently goes through the generic make_xfence_request() path with NULL data, incurring unnecessary per-VCPU checks. Split out a separate make_xfence_request_nodata() function to handle FENCE.I directly, and move the data validity check to the top of the generic function to avoid redundant checks. Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260731093833.1551341-3-wang.yechao255@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-01RISC-V: KVM: Separate req and fallback_req masks in make_xfence_requestWang Yechao1-8/+12
When handling hfence requests in make_xfence_request(), the current code uses a single 'actual_req' variable and a single vcpu_mask. If any VCPU fails to enqueue the hfence data (because its queue is full), the request falls back to 'fallback_req' for all VCPUs, even if other VCPUs still have available queue space. This can cause unnecessary fallback for healthy VCPUs, and more seriously, those healthy VCPUs will not process their already-enqueued hfence requests because no 'req' is set for them. As a result, their queues will quickly become full as well, degrading performance for SMP guests. Fix this by maintaining two separate bitmaps: one for VCPUs that successfully enqueued the hfence data (req_vcpu_mask) and another for those that failed (fallback_req_vcpu_mask). Then send the appropriate requests to each group. This ensures that fallback is only applied to VCPUs that actually need it, preserving the efficiency of the normal path for others. Fixes: 13acfec2dbcc ("RISC-V: KVM: Add remote HFENCE functions based on VCPU requests") Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260731093833.1551341-2-wang.yechao255@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-01RISC-V: KVM: Add the eager_page_split module parameterWang Yechao1-3/+10
Add an eager_page_split module parameter for RISC-V KVM, following the same approach as on x86. This parameter controls whether eager page splitting is enabled. The default value is on. When eager page splitting is enabled, KVM proactively splits large pages (huge pages) into smaller pages when needed for dirty logging or other operations. Disabling it can be beneficial for VM workloads that rarely perform writes, or that only write to a small region of memory, as it allows huge pages to remain intact for read accesses. Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260731091215.1549430-6-wang.yechao255@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-01RISC-V: KVM: Split huge pages during KVM_CLEAR_DIRTY_LOGWang Yechao1-0/+3
Split huge pages on the range specified using KVM_CLEAR_DIRTY_LOG. And do not split when enabling dirty logging if KVM_DIRTY_LOG_INITIALLY_SET is set. Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260731091215.1549430-5-wang.yechao255@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-01RISC-V: KVM: Remove redundant TLB flush operationsWang Yechao1-5/+6
The function kvm_arch_mmu_enable_log_dirty_pt_masked() is invoked from two distinct call paths: kvm_clear_dirty_log_protect() kvm_arch_mmu_enable_log_dirty_pt_masked() kvm_vm_ioctl_reset_dirty_pages() kvm_dirty_ring_reset() kvm_reset_dirty_gfn() kvm_arch_mmu_enable_log_dirty_pt_masked() In both scenarios, the caller already performs a remote TLB flush after dirty logging is enabled, so the TLB flush inside kvm_arch_mmu_enable_log_dirty_pt_masked() is unnecessary. Remove it. Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260731091215.1549430-4-wang.yechao255@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-01RISC-V: KVM: Split huge pages when dirty logging is enabledWang Yechao3-10/+95
Split huge pages eagerly when enabling dirty logging. The goal is to avoid doing it while faulting on write-protected pages, which negatively impacts guest performance. The benefits of eager page splitting are the same as in x86 and arm64, added with commit a3fe5dbda0a4 ("KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled") and commit e7bf7a490c68 ("KVM: arm64: Split huge pages when dirty logging is enabled") Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260731091215.1549430-3-wang.yechao255@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-01RISC-V: KVM: Add the split page cache for ioctl contextWang Yechao2-0/+4
Add the split page cache for dirty logging enablement and the KVM_CLEAR_DIRTY_LOG ioctl. Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260731091215.1549430-2-wang.yechao255@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-07-31x86/cpu/scattered: Sort it properlyBorislav Petkov (AMD)1-2/+2
Sort it according to the following precedence of struct cpuid_bit fields: (level) -> (sub_leaf) -> (reg) -> (bit). No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
generated by cgit (git 2.54.0.dirty) at 2026-09-22 17:45:11 +0000