kernel/linux.git/arch/arm64, branch v7.1.12

arm64: tegra: Add EL2 virtual timer interrupt for Tegra194

2026-08-23T12:29:29+00:00

[ Upstream commit a7c28483fd57dd0e1487024af70622315320774b ] Commit d87773de9efe ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE") updated the ARM arch timer driver to use the virtual timer by default if the CPU is running at EL2 with VHE enabled. If the CPU is running at EL2 with VHE enabled but there is no interrupt provided for the virtual timer, then the following warning is displayed: arch_timer: [Firmware Bug]: VHE-capable CPU without EL2 virtual timer interrupt This warning is observed on Tegra194 platforms. Tegra194 SoC includes NVIDIA Carmel ARM v8.2 CPUs and support an EL2 virtual timer. Fix the above warning by adding the PPI for the EL2 virtual timer interrupt for Tegra194. Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

arm64: remove redundant concurrent ptdump UAF mitigation

2026-08-19T16:20:29+00:00

commit 9d3277b2c07ccc9508d648098b3bbb46c61b7f3c upstream. This partially reverts commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), retaining vmalloc-huge support but eliminating the now redundant mitigation against a race between huge vmap page table freeing and ptdump, as this issue has now been fixed at core. We also simultaneously remove the arm64 if-deffery when acquiring the mmap read lock upon vmap huge page table promotion as it is no longer required. Note that this patch relies on the preceding vmalloc patch, and should not be backported alone. Link: https://lore.kernel.org/20260723-series-vmap-race-fix-v6-5-8cc77dcc0018@kernel.org Fixes: fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump") Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Dev Jain Acked-by: Mike Rapoport (Microsoft) Acked-by: Kiryl Shutsemau (Meta) Acked-by: Will Deacon Reviewed-by: David Hildenbrand (Arm) Cc: Andy Lutomirski Cc: "Borah, Chaitanya Kumar" Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Dave Hansen Cc: David Carlier Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Liam R. Howlett Cc: Michal Hocko Cc: Peter Zijlstra Cc: Ryan Roberts Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Toshi Kani Cc: "Uladzislau Rezki (Sony)" Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

arm64: dts: broadcom: bcm2712: Remove non-functional EL2 virtual timer

2026-08-19T16:20:13+00:00

[ Upstream commit 75952cfc7752c52a2b692b59d34ce160d3edabb2 ] Commit d87773de9efe1 ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE") causes boot to hang on Raspberry Pi 5. The newly-selected EL2 virtual timer does not generate any interrupts, even though the GIC_DIST_ENABLE_SET flag has been confirmed set via readback. It is highly unusual that this timer interrupt is non-operational because this is a standard GIC interrupt corresponding to a standard Cortex-A76 CPU timer. However, Broadcom have confirmed for this SoC: > the interrupt line was never connected in the first place as this was > not identified as being a requirement Remove the corresponding DeviceTree entry. Reported-by: Marek Szyprowski Closes: https://lore.kernel.org/all/ea15cce1-b393-43f6-8d58-3d6f90f0c0cd@samsung.com/ Fixes: faa3381267d0 ("arm64: dts: broadcom: Add minimal support for Raspberry Pi 5") Signed-off-by: Daniel Drake Link: https://lore.kernel.org/r/20260716-bcm2712-el2-v2-1-e708f7fb42fa@reactivated.net Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin

arm64: dts: qcom: sdm850-lenovo-yoga-c630: lower PSCI cluster idle

2026-08-19T16:20:13+00:00

[ Upstream commit 07db10de262f4150e24fd631a7a6c428f7bf80c9 ] With the default PSCI suspend value for cluster idle state Lenovo Yoga C630 isn't stable enough. For example it might reset if display device isn't probed early enough. Drop the bit 0x4000 from the PSCI suspend value to make C630 work in stable way. The bit was found by expertimenting with the cluster idle PSCI value. Most likely it results in the less deep sleep and more energy beign spent in the suspend state, but it's better than the non-stable system behaviour. Fixes: a1ade6cac5a2 ("arm64: dts: qcom: sdm845: Switch PSCI cpu idle states from PC to OSI") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260429-c630-fix-idle-v2-1-ac867dad6f21@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

arm64: dts: qcom: sm8650: Fix IPA IMEM slice

2026-08-19T16:20:13+00:00

[ Upstream commit 41d237b1546af5d5cf877175930cd23163422c83 ] Downstream the IPA IMEM slice for SM8650 is described as: qcom,additional-mapping = <0x14683000 0x14683000 0x2000>; Update upstream ipa_modem_tables to reflect downstream. Signed-off-by: Alexander Koskovich Fixes: 581fc5d5ade6 ("arm64: dts: qcom: sm8650: Explicitly describe the IPA IMEM slice") Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260415-fix-8650-ipa-modem-tables-v1-1-95f8f425e416@pm.me Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

arm64: dts: qcom: monaco: Add default GIC address cells

2026-08-19T16:20:13+00:00

[ Upstream commit d291245e2fb1eba55d751f88613a41e292958a96 ] Add missing address-cells 0 to GIC interrupt node to silence W=1 warning: monaco.dtsi:2326.4-2329.30: Warning (interrupt_map): /soc@0/pci@1c00000:interrupt-map: Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback Value '0' is correct because: 1. GIC interrupt controller does not have children, 2. interrupt-map property (in PCI node) consists of five components and the fourth component 'parent unit address', which size is defined by '#address-cells' of the node pointed to by the interrupt-parent component, is not used (=0). Fixes: 46a7c01e7e9d ("arm64: dts: qcom: qcs8300: enable pcie0") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260407201518.24949-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

arm64: dts: qcom: purwa: Fix GPU IOMMU property

2026-08-19T16:20:13+00:00

[ Upstream commit 4cd774c1feb3f720265c512174c5c3312eca1be2 ] Purwa's GPU does not support SID 1, which is typically used for LPAC-related traffic. Remove SID 1 from the GPU node's iommus property to accurately describe the hardware. This fixes the splat below, seen with some versions of Gunyah hypervisor: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 80 Comm: kworker/u33:2 Tainted: G M Tainted: [M]=MACHINE_CHECK Hardware name: Qualcomm Technologies, Inc. Purwa IoT EVK (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_write_s2cr+0x9c/0xbc lr : arm_smmu_master_install_s2crs+0x78/0xa4 sp : ffff80008039b570 x29: ffff80008039b570 x28: 0000000000000000 x27: ffffaddd62f1ab78 x26: ffff00080a4ff280 x25: 0000000000000018 x24: ffff00080b896480 x23: ffff00080ba9b7a0 x22: ffff00080bb05160 x21: 0000000000000000 x20: 0000000000000000 x19: 0000000000000001 x18: 00000000ffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008039b1d0 x14: ffff80010039b37d x13: 00746c7561662d74 x12: 0000000000000000 x11: ffff00080b7fbd98 x10: ffffffffffffffc0 x9 : ffffffffffffffff x8 : 0000000000000228 x7 : 0000000000000e87 x6 : 0000000000000000 x5 : 0000000000000000 x4 : ffff00080a4ff280 x3 : 0000000000000000 x2 : ffff800082a40c04 x1 : 0000000000000000 x0 : ffff800082a40000 Call trace: arm_smmu_write_s2cr+0x9c/0xbc (P) arm_smmu_master_install_s2crs+0x78/0xa4 arm_smmu_attach_dev+0xb0/0x1d8 __iommu_device_set_domain+0x84/0x11c __iommu_group_set_domain_internal+0x60/0x120 __iommu_attach_group+0x88/0x9c iommu_attach_device+0x6c/0xa0 msm_iommu_new.part.0+0x84/0xe4 [msm] msm_iommu_gpu_new+0x3c/0x104 [msm] adreno_iommu_create_vm+0x24/0xc8 [msm] a6xx_create_vm+0x48/0x78 [msm] msm_gpu_init+0x2d8/0x508 [msm] adreno_gpu_init+0x208/0x324 [msm] a6xx_gpu_init+0x604/0x8cc [msm] adreno_bind+0xb4/0x124 [msm] component_bind_all+0x114/0x23c msm_drm_init+0x1b0/0x1ec [msm] msm_drm_bind+0x30/0x3c [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x16c component_add+0x14/0x20 msm_dp_display_probe_tail+0x4c/0xac [msm] msm_dp_auxbus_done_probe+0x14/0x20 [msm] dp_aux_ep_probe+0x4c/0xf4 [drm_dp_aux_bus] really_probe+0xbc/0x29c __driver_probe_device+0x78/0x12c driver_probe_device+0x3c/0x15c __device_attach_driver+0xb8/0x134 bus_for_each_drv+0x88/0xe8 __device_attach+0xa0/0x190 device_initial_probe+0x50/0x54 bus_probe_device+0x38/0xa4 deferred_probe_work_func+0x88/0xc0 process_one_work+0x148/0x28c worker_thread+0x2cc/0x3d4 kthread+0x12c/0x204 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- Fixes: 1aa0b4e36436 ("arm64: dts: qcom: x1p42100: Add GPU support") Signed-off-by: Akhil P Oommen Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260410-purwa-gpu-dt-fix-v1-1-4637892156cf@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

arm64: dts: qcom: glymur: fix QUP serial engine IRQs

2026-08-19T16:20:13+00:00

[ Upstream commit a74a98f956ef8e075f28d58507bc5dad7f937fb4 ] The Geni serial-engine interrupts from QUP wrapper 0 all fall in ESPI INTIDs space. While some of the i2c instances has gotten their interrupt specifiers corrected, even the other functions on the same serial-engines are wrong. Ensure that all the serial engine interrupts for QUP wrapper 0 matches the datasheet. Assisted-by: Codex:GPT-5.5 Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260611-glymur-geni-irqs-v1-1-269428faeb6d@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

arm64: dts: qcom: glymur: fix PCIe SMMU interrupts

2026-08-19T16:20:12+00:00

[ Upstream commit 52c7084c8fe57c259e50ff0a7d4f99ccecfc4c7a ] The PCIe SMMUv3 wired interrupts are routed to GIC extended SPI INTIDs 4100, 4098 and 4096. Describe them as ESPIs with the ESPI-relative interrupt numbers instead of regular SPIs 964, 962 and 960. Assisted-by: Codex:GPT-5.5 Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi") Signed-off-by: Bjorn Andersson Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260611-glymur-pcie-smmu-espi-v1-1-5effbaa3e1af@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

KVM: arm64: Reject guest_memfd memslots when the VM has MTE

2026-08-09T18:26:26+00:00

[ Upstream commit 679d7201c1f09e37fa1c12ce28d84079c17fc87f ] The user cannot use MTE on VMAs created by mapping a guest_memfd file, as arch_calc_vm_flag_bits() does not set VM_MTE_ALLOWED. When creating a guest_memfd backed memslot, kvm_arch_prepare_memory_region() rejects the memslot if MTE is enabled for the VM and if guest_memfd has been mapped in a VMA that intersects the memslot. However, the documentation for KVM_SET_USER_MEMORY_REGION2 explicitly states that the only condition for userspace_addr is for it to be a legal userspace address, but the mapping is not required to be valid nor populated at memslot creation. If userspace sets userspace_addr to an address that hasn't been mapped, or if userspace_addr belongs to a VMA that isn't backed by the guest_memfd file, or if the VMA doesn't intersect the memslot, memslot creation is successful and KVM ends up with a VM with MTE and guest_memfd-backed memslots. The same happens if the order is reversed: when userspace enables MTE, KVM does not check if memslots backed by guest_memfd are already present. Fix both issues by rejecting guest_memfd-backed memslots when MTE is enabled, and by rejecting MTE when guest_memfd-backed memslots are already present. Fixes: 32e200bd6e44 ("KVM: arm64: Enable support for guest_memfd backed memory") Tested-by: Fuad Tabba Reviewed-by: Fuad Tabba Signed-off-by: Alexandru Elisei Link: https://patch.msgid.link/20260722090354.94245-1-alexandru.elisei@arm.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin