summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)Author
2025-06-19arm64: dts: rockchip: Enable gpu on rk3576-evb1-v10Andy Yan
Enable gpu for rk3576 evb. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Link: https://lore.kernel.org/r/20250618063609.690332-1-andyshrk@163.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: rockchip: Update the PinePhone Pro panel descriptionOlivier Benjamin
Fix a few issues in the panel section of the PinePhone Pro DTS: - add the second part of the Himax HX8394 LCD panel controller compatible - as proposed by Diederik de Haas, reuse the mipi_out and ports definitions from rk3399-base.dtsi instead of redefining them - add a pinctrl for the LCD_RST signal for LCD1, derived from LCD1_RST, which is on GPIO4_D1, as documented on pages 11 and 16 of the PinePhone Pro schematic Signed-off-by: Olivier Benjamin <olivier.benjamin@bootlin.com> Reviewed-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250619-dtb_fixes-v3-1-9cb02ddd8ce4@bootlin.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: renesas: rcar-gen3: Add bootph-all to sysinfo EEPROMsMarek Vasut
Add bootph-all property to sysinfo EEPROM on Renesas R-Car Gen3 Salvator-X(S), ULCB, Condor, Ebisu, Draak boards. The sysinfo EEPROM is used by U-Boot early on, mark it using the bootph-all property. No functional change for the Linux kernel, this only reduces the divergence of DTs between U-Boot and Linux. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250608215212.1619182-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: sparrow-hawk: Describe split PCIe clockMarek Vasut
The Sparrow Hawk board supplies the PCIe controller input clock and PCIe bus clock from separate outputs of the Renesas 9FGV0441 clock generator. Describe this split bus configuration in the board DT. The topology looks as follows: ____________ _____________ | R-Car PCIe | | PCIe device | | | | | | PCIe RX<|==================|>PCIe TX | | PCIe TX<|==================|>PCIe RX | | | | | | PCIe CLK<|======.. ..======|>PCIe CLK | '------------' || || '-------------' || || ____________ || || | 9FGV0441 | || || | | || || | CLK DIF0<|======'' || | CLK DIF1<|=========='' | CLK DIF2<| | CLK DIF3<| '------------' Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/20250607194541.79176-3-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r8a779g0: Describe PCIe root portsMarek Vasut
Add nodes which describe the root ports in the PCIe controller DT nodes. This can be used together with the pwrctrl driver to control clock and power supply to a PCIe slot. For example usage, refer to the Sparrow Hawk board. Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/20250607194541.79176-2-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: ebisu: Add CAN0 supportGeert Uytterhoeven
On R-Car E3, Classical CAN0/1 and CAN-FD share the same sets of pins, so only one of them can be used at the same time. Add support for using CAN0 instead of CAN-FD channel 0 on Ebisu. By default, only CAN-FD channel 0 is enabled, as before. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/612b999870dd64789041e4b0e9c568389b3fb95e.1749048320.git.geert+renesas@glider.be
2025-06-19arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable USB2.0 supportLad Prabhakar
Enable USB2.0 support on the RZ/V2N EVK board, CN2 connector on the EVK supports host/function operation. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250528140453.181851-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r9a09g056: Add USB2.0 supportLad Prabhakar
The Renesas RZ/V2N (R9A09G056) SoC features a single-channel USB2.0 interface with host and peripheral (function) support. Add the ECHI, OHCI, USB2.0 PHY and reset control nodes for USB2.0 channel in R9A09G056 SoC DTSI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250528140453.181851-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r8a779g3-sparrow-hawk: Sort DTSMarek Vasut
Sort DTS alphabetically. Fix up the placement of &rcar_sound {}. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250525160336.82960-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable USB2.0 supportLad Prabhakar
Enable USB2.0 support on the RZ/V2H EVK board, CN3 supports host only operation and CN2 supports host/function operation. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250515183104.330964-3-prabhakar.mahadev-lad.rj@bp.renesas.com Link: https://lore.kernel.org/20250613152216.201957-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: defconfig: Enable RZ/V2H(P) USB2 PHY controller reset driverLad Prabhakar
Enable the `CONFIG_RESET_RZV2H_USB2PHY` option in the arm64 defconfig to support the USB2 PHY controller reset driver on the Renesas RZ/V2H(P) SoC, as used on the RZ/V2H EVK board. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250513125858.251064-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19KVM: arm64: VHE: Centralize ISBs when returning to hostMark Rutland
The VHE hyp code has recently gained a few ISBs. Simplify this to one unconditional ISB in __kvm_vcpu_run_vhe(), and remove the unnecessary ISB from the kvm_call_hyp_ret() macro. While kvm_call_hyp_ret() is also used to invoke __vgic_v3_get_gic_config(), but no ISB is necessary in that case either. For the moment, an ISB is left in kvm_call_hyp(), as there are many more users, and removing the ISB would require a more thorough audit. Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250617133718.4014181-8-mark.rutland@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-19KVM: arm64: Remove cpacr_clear_set()Mark Rutland
We no longer use cpacr_clear_set(). Remove cpacr_clear_set() and its helper functions. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250617133718.4014181-7-mark.rutland@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-19KVM: arm64: Remove ad-hoc CPTR manipulation from kvm_hyp_handle_fpsimd()Mark Rutland
The hyp code FPSIMD/SVE/SME trap handling logic has some rather messy open-coded manipulation of CPTR/CPACR. This is benign for non-nested guests, but broken for nested guests, as the guest hypervisor's CPTR configuration is not taken into account. Consider the case where L0 provides FPSIMD+SVE to an L1 guest hypervisor, and the L1 guest hypervisor only provides FPSIMD to an L2 guest (with L1 configuring CPTR/CPACR to trap SVE usage from L2). If the L2 guest triggers an FPSIMD trap to the L0 hypervisor, kvm_hyp_handle_fpsimd() will see that the vCPU supports FPSIMD+SVE, and will configure CPTR/CPACR to NOT trap FPSIMD+SVE before returning to the L2 guest. Consequently the L2 guest would be able to manipulate SVE state even though the L1 hypervisor had configured CPTR/CPACR to forbid this. Clean this up, and fix the nested virt issue by always using __deactivate_cptr_traps() and __activate_cptr_traps() to manage the CPTR traps. This removes the need for the ad-hoc fixup in kvm_hyp_save_fpsimd_host(), and ensures that any guest hypervisor configuration of CPTR/CPACR is taken into account. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250617133718.4014181-6-mark.rutland@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-19KVM: arm64: Remove ad-hoc CPTR manipulation from fpsimd_sve_sync()Mark Rutland
There's no need for fpsimd_sve_sync() to write to CPTR/CPACR. All relevant traps are always disabled earlier within __kvm_vcpu_run(), when __deactivate_cptr_traps() configures CPTR/CPACR. With irrelevant details elided, the flow is: handle___kvm_vcpu_run(...) { flush_hyp_vcpu(...) { fpsimd_sve_flush(...); } __kvm_vcpu_run(...) { __activate_traps(...) { __activate_cptr_traps(...); } do { __guest_enter(...); } while (...); __deactivate_traps(....) { __deactivate_cptr_traps(...); } } sync_hyp_vcpu(...) { fpsimd_sve_sync(...); } } Remove the unnecessary write to CPTR/CPACR. An ISB is still necessary, so a comment is added to describe this requirement. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250617133718.4014181-5-mark.rutland@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-19KVM: arm64: Reorganise CPTR trap manipulationMark Rutland
The NVHE/HVHE and VHE modes have separate implementations of __activate_cptr_traps() and __deactivate_cptr_traps() in their respective switch.c files. There's some duplication of logic, and it's not currently possible to reuse this logic elsewhere. Move the logic into the common switch.h header so that it can be reused, and de-duplicate the common logic. This rework changes the way SVE traps are deactivated in VHE mode, aligning it with NVHE/HVHE modes: * Before this patch, VHE's __deactivate_cptr_traps() would unconditionally enable SVE for host EL2 (but not EL0), regardless of whether the ARM64_SVE cpucap was set. * After this patch, VHE's __deactivate_cptr_traps() will take the ARM64_SVE cpucap into account. When ARM64_SVE is not set, SVE will be trapped from EL2 and below. The old and new behaviour are both benign: * When ARM64_SVE is not set, the host will not touch SVE state, and will not reconfigure SVE traps. Host EL0 access to SVE will be trapped as expected. * When ARM64_SVE is set, the host will configure EL0 SVE traps before returning to EL0 as part of reloading the EL0 FPSIMD/SVE/SME state. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250617133718.4014181-4-mark.rutland@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-19KVM: arm64: VHE: Synchronize CPTR trap deactivationMark Rutland
Currently there is no ISB between __deactivate_cptr_traps() disabling traps that affect EL2 and fpsimd_lazy_switch_to_host() manipulating registers potentially affected by CPTR traps. When NV is not in use, this is safe because the relevant registers are only accessed when guest_owns_fp_regs() && vcpu_has_sve(vcpu), and this also implies that SVE traps affecting EL2 have been deactivated prior to __guest_entry(). When NV is in use, a guest hypervisor may have configured SVE traps for a nested context, and so it is necessary to have an ISB between __deactivate_cptr_traps() and fpsimd_lazy_switch_to_host(). Due to the current lack of an ISB, when a guest hypervisor enables SVE traps in CPTR, the host can take an unexpected SVE trap from within fpsimd_lazy_switch_to_host(), e.g. | Unhandled 64-bit el1h sync exception on CPU1, ESR 0x0000000066000000 -- SVE | CPU: 1 UID: 0 PID: 164 Comm: kvm-vcpu-0 Not tainted 6.15.0-rc4-00138-ga05e0f012c05 #3 PREEMPT | Hardware name: FVP Base RevC (DT) | pstate: 604023c9 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __kvm_vcpu_run+0x6f4/0x844 | lr : __kvm_vcpu_run+0x150/0x844 | sp : ffff800083903a60 | x29: ffff800083903a90 x28: ffff000801f4a300 x27: 0000000000000000 | x26: 0000000000000000 x25: ffff000801f90000 x24: ffff000801f900f0 | x23: ffff800081ff7720 x22: 0002433c807d623f x21: ffff000801f90000 | x20: ffff00087f730730 x19: 0000000000000000 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff000801f90d70 | x5 : 0000000000001000 x4 : ffff8007fd739000 x3 : ffff000801f90000 | x2 : 0000000000000000 x1 : 00000000000003cc x0 : ffff800082f9d000 | Kernel panic - not syncing: Unhandled exception | CPU: 1 UID: 0 PID: 164 Comm: kvm-vcpu-0 Not tainted 6.15.0-rc4-00138-ga05e0f012c05 #3 PREEMPT | Hardware name: FVP Base RevC (DT) | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x60/0x80 | dump_stack+0x18/0x24 | panic+0x168/0x360 | __panic_unhandled+0x68/0x74 | el1h_64_irq_handler+0x0/0x24 | el1h_64_sync+0x6c/0x70 | __kvm_vcpu_run+0x6f4/0x844 (P) | kvm_arm_vcpu_enter_exit+0x64/0xa0 | kvm_arch_vcpu_ioctl_run+0x21c/0x870 | kvm_vcpu_ioctl+0x1a8/0x9d0 | __arm64_sys_ioctl+0xb4/0xf4 | invoke_syscall+0x48/0x104 | el0_svc_common.constprop.0+0x40/0xe0 | do_el0_svc+0x1c/0x28 | el0_svc+0x30/0xcc | el0t_64_sync_handler+0x10c/0x138 | el0t_64_sync+0x198/0x19c | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x0000,000002c0,02df4fb9,97ee773f | Memory Limit: none | ---[ end Kernel panic - not syncing: Unhandled exception ]--- Fix this by adding an ISB between __deactivate_traps() and fpsimd_lazy_switch_to_host(). Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250617133718.4014181-3-mark.rutland@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-19KVM: arm64: VHE: Synchronize restore of host debug registersMark Rutland
When KVM runs in non-protected VHE mode, there's no context synchronization event between __debug_switch_to_host() restoring the host debug registers and __kvm_vcpu_run() unmasking debug exceptions. Due to this, it's theoretically possible for the host to take an unexpected debug exception due to the stale guest configuration. This cannot happen in NVHE/HVHE mode as debug exceptions are masked in the hyp code, and the exception return to the host will provide the necessary context synchronization before debug exceptions can be taken. For now, avoid the problem by adding an ISB after VHE hyp code restores the host debug registers. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: Will Deacon <will@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250617133718.4014181-2-mark.rutland@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-19KVM: arm64: Explicitly treat routing entry type changes as changesSean Christopherson
Explicitly treat type differences as GSI routing changes, as comparing MSI data between two entries could get a false negative, e.g. if userspace changed the type but left the type-specific data as- Note, the same bug was fixed in x86 by commit bcda70c56f3e ("KVM: x86: Explicitly treat routing entry type changes as changes"). Fixes: 4bf3693d36af ("KVM: arm64: Unmap vLPIs affected by changes to GSI routing information") Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20250611224604.313496-3-seanjc@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-19KVM: arm64: nv: Fix tracking of shadow list registersMarc Zyngier
Wei-Lin reports that the tracking of shadow list registers is majorly broken when resync'ing the L2 state after a run, as we confuse the guest's LR index with the host's, potentially losing the interrupt state. While this could be fixed by adding yet another side index to track it (Wei-Lin's fix), it may be better to refactor this code to avoid having a side index altogether, limiting the risk to introduce this class of bugs. A key observation is that the shadow index is always the number of bits in the lr_map bitmap. With that, the parallel indexing scheme can be completely dropped. While doing this, introduce a couple of helpers that abstract the index conversion and some of the LR repainting, making the whole exercise much simpler. Reported-by: Wei-Lin Chang <r09922117@csie.ntu.edu.tw> Reviewed-by: Wei-Lin Chang <r09922117@csie.ntu.edu.tw> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250614145721.2504524-1-r09922117@csie.ntu.edu.tw Link: https://lore.kernel.org/r/86qzzkc5xa.wl-maz@kernel.org
2025-06-19arm64: defconfig: add S32G RTC module supportCiprian Marian Costea
The RTC hardware module present on S32G based SoCs tracks clock time during system suspend and it is used as a wakeup source on S32G2/S32G3 architecture. Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-19arm64: dts: imx8mp-venice-gw74xx: fix TPM SPI frequencyTim Harvey
The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 531936b218d8 ("arm64: dts: imx8mp-venice-gw74xx: update to revB PCB") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-19arm64: dts: imx8mp-venice-gw73xx: fix TPM SPI frequencyTim Harvey
The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 2b3ab9d81ab4 ("arm64: dts: imx8mp-venice-gw73xx: add TPM device") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-19arm64: dts: imx8mp-venice-gw72xx: fix TPM SPI frequencyTim Harvey
The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 5016f22028e4 ("arm64: dts: imx8mp-venice-gw72xx: add TPM device") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-19arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequencyTim Harvey
The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 1a8f6ff6a291 ("arm64: dts: imx8mp-venice-gw71xx: add TPM device") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey <tharvey@gateworks.com> Link: https://lore.kernel.org/stable/20250523173723.4167474-1-tharvey%40gateworks.com Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-19arm64: dts: add ngpios for vf610 compatible gpio controllersHaibo Chen
After commit da5dd31efd24 ("gpio: vf610: Switch to gpio-mmio"), the vf610 GPIO driver no longer uses the static number 32 for gc->ngpio. This allows users to configure the number of GPIOs per port. And some gpio controllers did have less pads. So add 'ngpios' here, this can save some memory when request bitmap, and also show user more accurate information when use gpio tools. Besides, some gpio controllers have hole in the gpio ranges, so use 'gpio-reserved-ranges' to cover that, then the gpioinfo tool show the correct result. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-18arm64: dts: qcom: sm8650: add iris DT nodeNeil Armstrong
Add DT entries for the sm8650 iris decoder. Since the firmware is required to be signed, only enable on Qualcomm development boards where the firmware is available. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250613-topic-sm8x50-upstream-iris-8650-dt-v4-1-35ea7952f2d2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-18Merge tag 'libcrypto-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux Pull crypto library fixes from Eric Biggers: - Fix a regression in the arm64 Poly1305 code - Fix a couple compiler warnings * tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: lib/crypto/poly1305: Fix arm64's poly1305_blocks_arch() lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older lib/crypto: Annotate crypto strings with nonstring
2025-06-18arm64: dts: qcom: msm8976-longcheer-l9360: Add initial device treeAndré Apitzsch
This dts adds support for BQ Aquaris X5 Plus (Longcheer L9360) released in 2016. Add a device tree with initial support for: - GPIO keys - NFC - SDHCI - Status LED - Touchscreen Signed-off-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20250615-bqx5plus-v2-4-72b45c84237d@apitzsch.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-18arm64: dts: qcom: msm8976: Add sdc2 GPIOsAndré Apitzsch
Downstream vendor code for reference: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.3.7.c26/arch/arm/boot/dts/qcom/msm8976-pinctrl.dtsi#L223-263 Signed-off-by: André Apitzsch <git@apitzsch.eu> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250615-bqx5plus-v2-3-72b45c84237d@apitzsch.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-18arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotelyAndré Apitzsch
The blsp_dma controller is shared between the different subsystems, which is why it is already initialized by the firmware. We should not reinitialize it from Linux to avoid potential other users of the DMA engine to misbehave. In mainline this can be described using the "qcom,controlled-remotely" property. In the downstream/vendor kernel from Qualcomm there is an opposite "qcom,managed-locally" property. This property is *not* set for the qcom,sps-dma@7884000 and qcom,sps-dma@7ac4000 [1] so adding "qcom,controlled-remotely" upstream matches the behavior of the downstream/vendor kernel. Adding this fixes booting Longcheer L9360. [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.3.7.c26/arch/arm/boot/dts/qcom/msm8976.dtsi#L1149-1163 Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20250615-bqx5plus-v2-1-72b45c84237d@apitzsch.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-18arm64: dts: qcom: sa8775p: Correct the interrupt for remoteprocLijuan Gao
Fix the incorrect IRQ numbers for ready and handover on sa8775p. The correct values are as follows: Fatal interrupt - 0 Ready interrupt - 1 Handover interrupt - 2 Stop acknowledge interrupt - 3 Fixes: df54dcb34ff2e ("arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP nodes") Signed-off-by: Lijuan Gao <lijuan.gao@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250612-correct_interrupt_for_remoteproc-v1-2-490ee6d92a1b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-18arm64: dts: exynos: gs101: Add 'local-timer-stop' to cpuidle nodesWill Deacon
In preparation for switching to the architected timer as the primary clockevents device, mark the cpuidle nodes with the 'local-timer-stop' property to indicate that an alternative clockevents device must be used for waking up from the "c2" idle state. Signed-off-by: Will Deacon <willdeacon@google.com> [Original commit from https://android.googlesource.com/kernel/gs/+/a896fd98638047989513d05556faebd28a62b27c] Signed-off-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Youngmin Nam <youngmin.nam@samsung.com> Tested-by: Youngmin Nam <youngmin.nam@samsung.com> Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250611-gs101-cpuidle-v2-1-4fa811ec404d@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-18arm64: dts: exynosautov920: Add DT node for all SPI portsFaraz Ata
Universal Serial Interface (USI) supports three serial protocol like uart, i2c and spi. ExynosAutov920 has 18 instances of USI. Add spi nodes for all the instances. Signed-off-by: Faraz Ata <faraz.ata@samsung.com> Link: https://lore.kernel.org/r/20250613062208.978641-1-faraz.ata@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-18pinctrl: stm32: Allow compile as module for stm32mp257Stephane Danieau
Add ability to build pinctrl for stm32mp257 as a kernel module. Add kernel-doc to the exported symbols. Signed-off-by: Stephane Danieau <stephane.danieau@foss.st.com> Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Link: https://lore.kernel.org/20250610143042.295376-5-antonio.borneo@foss.st.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-17arm64: dts: qcom: sm8550: Add support for camssWenmeng Liu
Add support for the camera subsystem on the SM8550 Qualcomm SoC. This includes bringing up the CSIPHY, CSID, VFE/RDI interfaces. SM8550 provides - 3 x VFE, 3 RDI per VFE - 2 x VFE Lite, 4 RDI per VFE - 3 x CSID - 2 x CSID Lite - 8 x CSI PHY Co-developed-by: Depeng Shao <quic_depengs@quicinc.com> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com> Signed-off-by: Wenmeng Liu <quic_wenmliu@quicinc.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20250612-sm8550-camss-v2-1-ed370124075e@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: qcs615: disable the CTI device of the camera blockJie Gan
Disable the CTI device of the camera block to prevent potential NoC errors during AMBA bus device matching. The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp through a mailbox. However, the camera block resides outside the AP domain, meaning its QDSS clock cannot be controlled via aoss_qmp. Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250611030003.3801-1-jie.gan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: qcs615-ride: enable remoteprocsLijuan Gao
Enable all remoteproc nodes on the qcs615-ride board and point to the appropriate firmware files to allow proper functioning of the remote processors. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Lijuan Gao <quic_lijuang@quicinc.com> Link: https://lore.kernel.org/r/20250526-add_qcs615_remoteproc_support-v4-6-06a7d8bed0b5@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: qcs615: add ADSP and CDSP nodesLijuan Gao
Add nodes for remoteprocs: ADSP and CDSP for QCS615 SoC to enable proper remoteproc functionality. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Lijuan Gao <quic_lijuang@quicinc.com> Link: https://lore.kernel.org/r/20250526-add_qcs615_remoteproc_support-v4-5-06a7d8bed0b5@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: qcs615: Add IMEM and PIL info regionLijuan Gao
Add a simple-mfd representing IMEM on QCS615 and define the PIL relocation info region as its child. The PIL region in IMEM is used to communicate load addresses of remoteproc to post mortem debug tools, so that these tools can collect ramdumps. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Lijuan Gao <quic_lijuang@quicinc.com> Link: https://lore.kernel.org/r/20250526-add_qcs615_remoteproc_support-v4-4-06a7d8bed0b5@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: qcs615: Add mproc node for SEMP2PKyle Deng
The Shared Memory Point to Point (SMP2P) protocol facilitates communication of a single 32-bit value between two processors. Add these two nodes for remoteproc enablement on QCS615 SoC. Signed-off-by: Kyle Deng <quic_chunkaid@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Lijuan Gao <quic_lijuang@quicinc.com> Link: https://lore.kernel.org/r/20250526-add_qcs615_remoteproc_support-v4-3-06a7d8bed0b5@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: Add support for X1-based Asus Zenbook A14Aleksandrs Vinarskis
Initial support for Asus Zenbook A14. Particular moddel exists in X1-26-100, X1P-42-100 (UX3407QA) and X1E-78-100 (UX3407RA). Mostly similar to other X1-based laptops. Notable differences are: * Wifi/Bluetooth combo being Qualcomm FastConnect 6900 on UX3407QA and Qualcomm FastConnect 7800 on UX3407RA * USB Type-C retimers are Parade PS8833, appear to behave identical to Parade PS8830 * gpio90 is TZ protected Working: * Keyboard * Touchpad * NVME * Lid switch * Camera LED * eDP (FHD OLED, SDC420D) with brightness control * Bluetooth, WiFi (WCN6855) * USB Type-A port * USB Type-C ports in USB2/USB3/DP (both orientations) * aDSP/cDPS firmware loading, battery info * Sleep/suspend, nothing visibly broken on resume Out of scope of this series: * Audio (Speakers/microphones/headphone jack) * Camera (OmniVision OV02C10) * HDMI (Parade PS185HDM) * EC Add dtsi and create two configurations for UX3407QA, UX3407RA. Tested on UX3407QA with X1-26-100. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Link: https://lore.kernel.org/r/20250523131605.6624-2-alex.vinarskis@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: sc7180: Expand IMEM regionKonrad Dybcio
We need more than what is currently described, expand the region to its actual boundaries. Fixes: ede638c42c82 ("arm64: dts: qcom: sc7180: Add IMEM and pil info regions") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250523-topic-ipa_mem_dts-v1-3-f7aa94fac1ab@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: sdm845: Expand IMEM regionKonrad Dybcio
We need more than what is currently described, expand the region to its actual boundaries. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 948f6161c6ab ("arm64: dts: qcom: sdm845: Add IMEM and PIL info region") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250523-topic-ipa_mem_dts-v1-2-f7aa94fac1ab@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for ↵Jie Gan
Coresight An infinite loop has been created by the Coresight devices. When only a source device is enabled, the coresight_find_activated_sysfs_sink function is recursively invoked in an attempt to locate an active sink device, ultimately leading to a stack overflow and system crash. Therefore, disable the replicator1 to break the infinite loop and prevent a potential stack overflow. replicator1_out -> funnel_swao_in6 -> tmc_etf_swao_in -> tmc_etf_swao_out | | replicator1_in replicator_swao_in | | replicator0_out1 replicator_swao_out0 | | replicator0_in funnel_in1_in3 | | tmc_etf_out <- tmc_etf_in <- funnel_merg_out <- funnel_merg_in1 <- funnel_in1_out [call trace] dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 dump_stack+0x18/0x28 panic+0x340/0x3b0 nmi_panic+0x94/0xa0 panic_bad_stack+0x114/0x138 handle_bad_stack+0x34/0xb8 __bad_stack+0x78/0x80 coresight_find_activated_sysfs_sink+0x28/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] ... coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_enable_sysfs+0x80/0x2a0 [coresight] side effect after the change: Only trace data originating from AOSS can reach the ETF_SWAO and EUD sinks. Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20250522005016.2148-1-jie.gan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: sm6350: add APR and some audio-related servicesLuca Weiss
Add the APR node and its associated services required for audio on the SM6350 SoC. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250321-sm6350-apr-v1-1-7805ce7b4dcf@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: qcm2290: Add CAMSS nodeLoic Poulain
Add node for the QCM2290 camera subsystem. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423072044.234024-7-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: sa8775p-ride: enable videoVikash Garodia
Enable video nodes on the sa8775p-ride board and point to the appropriate firmware files. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com> Link: https://lore.kernel.org/r/20250421-dtbinding-v5-3-363c1c05bc80@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: sa8775p: add support for video nodeVikash Garodia
Video node enables video on Qualcomm SA8775P platform. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com> Link: https://lore.kernel.org/r/20250421-dtbinding-v5-2-363c1c05bc80@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-17arm64: dts: qcom: sa8775p: Add CPU OPP tables to scale DDR/L3Jagadeesh Kona
Add OPP tables required to scale DDR and L3 per freq-domain on SA8775P platform. If a single OPP table is used for both CPU domains, then _allocate_opp_table() won't be invoked for CPU4 but instead CPU4 will be added as device under the CPU0 OPP table. Due to this, dev_pm_opp_of_find_icc_paths() won't be invoked for CPU4 device and hence CPU4 won't be able to independently scale it's interconnects. Both CPU0 and CPU4 devices will scale the same ICC path which can lead to one device overwriting the BW vote placed by other device. Hence CPU0 and CPU4 require separate OPP tables to allow independent scaling of DDR and L3 frequencies for each CPU domain, with the final DDR and L3 frequencies being an aggregate of both. Co-developed-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> Signed-off-by: Raviteja Laggyshetty <quic_rlaggysh@quicinc.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250415095343.32125-8-quic_rlaggysh@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>