summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-04-01arm64: fpsimd: Remove obsolete cond_yield macroEric Biggers
All invocations of the cond_yield macro have been removed, so remove the macro definition as well. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20260401000548.133151-10-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-04-01lib/crypto: arm64/aes: Remove obsolete chunking logicEric Biggers
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode NEON at context switch"), kernel-mode NEON sections have been preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"), voluntary preemption is no longer supported on arm64 either. Therefore, there's no longer any need to limit the length of kernel-mode NEON sections on arm64. Simplify the AES-CBC-MAC code accordingly. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20260401000548.133151-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-04-01MIPS: mm: Rewrite TLB uniquification for the hidden bit featureMaciej W. Rozycki
Before the introduction of the EHINV feature, which lets software mark TLB entries invalid, certain older implementations of the MIPS ISA were equipped with an analogous bit, as a vendor extension, which however is hidden from software and only ever set at reset, and then any software write clears it, making the intended TLB entry valid. This feature makes it unsafe to read a TLB entry with TLBR, modify the page mask, and write the entry back with TLBWI, because this operation will implicitly clear the hidden bit and this may create a duplicate entry, as with the presence of the hidden bit there is no guarantee all the entries across the TLB are unique each. Usually the firmware has already uniquified TLB entries before handing control over, in which case we only need to guarantee at bootstrap no clash will happen with the VPN2 values chosen in local_flush_tlb_all(). However with systems such as Mikrotik RB532 we get handed the TLB as at reset, with the hidden bit set across the entries and possibly duplicate entries present. This then causes a machine check exception when page sizes are reset in r4k_tlb_uniquify() and prevents the system from booting. Rewrite the algorithm used in r4k_tlb_uniquify() then such as to avoid the reuse of ASID/VPN values across the TLB. Get rid of global entries first as they may be blocking the entire address space, e.g. 16 256MiB pages will exhaust the whole address space of a 32-bit CPU and a single big page can exhaust the 32-bit compatibility space on a 64-bit CPU. Details of the algorithm chosen are given across the code itself. Fixes: 9f048fa48740 ("MIPS: mm: Prevent a TLB shutdown on initial uniquification") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-04-01MIPS: mm: Suppress TLB uniquification on EHINV hardwareMaciej W. Rozycki
Hardware that supports the EHINV feature, mandatory for R6 ISA and FTLB implementation, lets software mark TLB entries invalid, which eliminates the need to ensure no duplicate matching entries are ever created. This feature is already used by local_flush_tlb_all(), via the UNIQUE_ENTRYHI macro, making the preceding call to r4k_tlb_uniquify() superfluous. The next change will also modify uniquification code such that it'll become incompatible with the FTLB and MMID features, as well as MIPSr6 CPUs that do not implement 4KiB pages. Therefore prevent r4k_tlb_uniquify() from being used on EHINV hardware, as denoted by `cpu_has_tlbinv'. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-04-01MIPS: Always record SEGBITS in cpu_data.vmbitsMaciej W. Rozycki
With a 32-bit kernel running on 64-bit MIPS hardware the hardcoded value of `cpu_vmbits' only records the size of compatibility useg and does not reflect the size of native xuseg or the complete range of values allowed in the VPN2 field of TLB entries. An upcoming change will need the actual VPN2 value range permitted even in 32-bit kernel configurations, so always include the `vmbits' member in `struct cpuinfo_mips' and probe for SEGBITS when running on 64-bit hardware and resorting to the currently hardcoded value of 31 on 32-bit processors. No functional change for users of `cpu_vmbits'. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-04-01MIPS: Fix the GCC version check for `__multi3' workaroundMaciej W. Rozycki
It was only GCC 10 that fixed a MIPS64r6 code generation issue with a `__multi3' libcall inefficiently produced to perform 64-bit widening multiplication while suitable machine instructions exist to do such a calculation. The fix went in with GCC commit 48b2123f6336 ("re PR target/82981 (unnecessary __multi3 call for mips64r6 linux kernel)"). Adjust our code accordingly, removing build failures such as: mips64-linux-ld: lib/math/div64.o: in function `mul_u64_add_u64_div_u64': div64.c:(.text+0x84): undefined reference to `__multi3' with the GCC versions affected. Fixes: ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601140146.hMLODc6v-lkp@intel.com/ Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v4.15+ Reviewed-by: David Laight <david.laight.linux@gmail.com. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-04-01MIPS: SiByte: Bring back cache initialisationMaciej W. Rozycki
Bring back cache initialisation for Broadcom SiByte SB1 cores, which has been removed causing the kernel to hang at bootstrap right after: Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes, linear) Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes, linear) The cause of the problem is R4k cache handlers are also used by Broadcom SiByte SB1 cores, however with a different cache error exception handler and therefore not using CPU_R4K_CACHE_TLB: obj-$(CONFIG_CPU_R4K_CACHE_TLB) += c-r4k.o cex-gen.o tlb-r4k.o obj-$(CONFIG_CPU_SB1) += c-r4k.o cerr-sb1.o cex-sb1.o tlb-r4k.o (from arch/mips/mm/Makefile). Fixes: bbe4f634f48c ("mips: fix r3k_cache_init build regression") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-04-01mips: ralink: update CPU clock indexShiji Yang
Update CPU clock index to match the clock driver changes. Fixes: d34db686a3d7 ("clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs") Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com> Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-04-01MIPS: Loongson64: env: Check UARTs passed by LEFI cautiouslyRong Zhang
Some firmware does not set nr_uarts properly and passes empty items. Iterate at most min(system->nr_uarts, MAX_UARTS) items to prevent out-of-bounds access, and ignore UARTs with addr 0 silently. Meanwhile, our DT only works with UPIO_MEM but theoretically firmware may pass other IO types, so explicitly check against that. Tested on Loongson-LS3A4000-7A1000-NUC-SE. Fixes: 3989ed418483 ("MIPS: Loongson64: env: Fixup serial clock-frequency when using LEFI") Cc: stable@vger.kernel.org Reviewed-by: Yao Zi <me@ziyao.cc> Signed-off-by: Rong Zhang <rongrong@oss.cipunited.com> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-04-01x86/CPU/AMD: Print AGESA string from DMI additional information entryYazen Ghannam
Type 40 entries (Additional Information) are summarized in section 7.41 as part of the SMBIOS specification. Generally, these entries aren't interesting to save. However on some AMD Zen systems, the AGESA version is stored here. This is useful to save to the kernel message logs for debugging. It can be used to cross-reference issues. Implement an iterator for the Additional Information entries. Use this to find and print the AGESA string. Do so in AMD code, since the use case is AMD-specific. [ bp: Match only "AGESA". ] Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Co-developed-by: "Mario Limonciello (AMD)" <superm1@kernel.org> Signed-off-by: "Mario Limonciello (AMD)" <superm1@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Jean Delvare <jdelvare@suse.de> Link: https://patch.msgid.link/20260307141024.819807-6-superm1@kernel.org
2026-04-01Merge tag 'renesas-dts-for-v7.1-tag2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt Renesas DTS updates for v7.1 (take two) - Add DT overlay support for the MayQueen PixPaper display on the Yuridenki-Shokai Kakip board, - Add Ethernet PHY interrupt support for the RZ/T2H and RZ/N2H EVK boards, - Add SPI and PCIe support for the RZ/G3E SoC and the RZ/G3E SMARC EVK board, - Add DT overlay support for the WaveShare 13.3" 1920x1080 DSI Capacitive Touch Display and the Olimex MIPI-HDMI adapter on the Retronix Sparrow Hawk board, - Drop several superfluous C22 Ethernet PHY compatible strings, - Remove WDT nodes meant for other CPU cores on the RZ/V2N SoC, - Remove unavailable LVDS panel support for the Beacon ReneSoM base board, - Add initial support for the RZ/G3L (R9A08G046) SoC, and the RZ/G3L SMARC SoM and EVK boards, - Add Versa3 clock generator support for the RZ/V2H EVK development board, - Miscellaneous fixes and improvements. * tag 'renesas-dts-for-v7.1-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (29 commits) ARM: dts: renesas: Drop KSZ8041 PHY C22 compatible strings ARM: dts: renesas: rza2mevb: Drop RTL8201F PHY C22 compatible string ARM: dts: renesas: r8a7742-iwg21d-q7-dbcm-ca: Drop KSZ8081 PHY C22 compatible string arm64: dts: renesas: Add initial device tree for RZ/G3L SMARC EVK board arm64: dts: renesas: renesas-smarc2: Move usb3 nodes to board DTS arm64: dts: renesas: Add initial support for RZ/G3L SMARC SoM arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add versa3 clock generator node dt-bindings: clock: renesas,rzg2l-cpg: Document RZ/G3L SoC arm64: dts: renesas: beacon-renesom: Remove LVDS Panel ARM: dts: r9a06g032: Add #address-cells to the GIC node arm64: dts: renesas: r9a09g056: Remove wdt{0,2,3} nodes arm64: dts: renesas: sparrow-hawk: Add overlay for Olimex MIPI-HDMI adapter arm64: dts: renesas: r9a09g047e57-smarc: Enable PCIe arm64: dts: renesas: r9a09g047e57-smarc-som: Add PCIe reference clock arm64: dts: renesas: r9a09g047: Add PCIe node arm64: dts: renesas: Fix KSZ9131 PHY bogus txdv-skew-psec properties arm64: dts: renesas: Drop KSZ9131 PHY C22 compatible strings arm64: dts: renesas: Drop RTL8211F PHY C22 compatible strings arm64: dts: renesas: Drop RTL8211E PHY C22 compatible strings ... Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-01arm64: mm: Use generic enum pgtable_levelKevin Brodsky
enum pgtable_type was introduced for arm64 by commit c64f46ee1377 ("arm64: mm: use enum to identify pgtable level instead of *_SHIFT"). In the meantime, the generic enum pgtable_level got introduced by commit b22cc9a9c7ff ("mm/rmap: convert "enum rmap_level" to "enum pgtable_level""). Let's switch to the generic enum pgtable_level. The only difference is that it also includes PGD level; __pgd_pgtable_alloc() isn't expected to create PGD tables so we add a VM_WARN_ON() for that case. Suggested-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-04-01arm64/mm: Reject memory removal that splits a kernel leaf mappingAnshuman Khandual
Linear and vmemmap mappings that get torn down during a memory hot remove operation might contain leaf level entries on any page table level. If the requested memory range's linear or vmemmap mappings falls within such leaf entries, new mappings need to be created for the remaining memory mapped on the leaf entry earlier, following standard break before make aka BBM rules. But kernel cannot tolerate BBM and hence remapping to fine grained leaves would not be possible on systems without BBML2_NOABORT. Currently memory hot remove operation does not perform such restructuring, and so removing memory ranges that could split a kernel leaf level mapping need to be rejected. While memory_hotplug.c does appear to permit hot removing arbitrary ranges of memory, the higher layers that drive memory_hotplug (e.g. ACPI, virtio, ...) all appear to treat memory as fixed size devices. So it is impossible to hot unplug a different amount than was previously hot plugged, and hence we should never see a rejection in practice, but adding the check makes us robust against a future change. Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/all/aWZYXhrT6D2M-7-N@willie-the-truck/ Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Suggested-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-04-01arm64/mm: Enable batched TLB flush in unmap_hotplug_range()Anshuman Khandual
During a memory hot remove operation, both linear and vmemmap mappings for the memory range being removed, get unmapped via unmap_hotplug_range() but mapped pages get freed only for vmemmap mapping. This is just a sequential operation where each table entry gets cleared, followed by a leaf specific TLB flush, and then followed by memory free operation when applicable. This approach was simple and uniform both for vmemmap and linear mappings. But linear mapping might contain CONT marked block memory where it becomes necessary to first clear out all entire in the range before a TLB flush. This is as per the architecture requirement. Hence batch all TLB flushes during the table tear down walk and finally do it in unmap_hotplug_range(). Prior to this fix, it was hypothetically possible for a speculative access to a higher address in the contiguous block to fill the TLB with shattered entries for the entire contiguous range after a lower address had already been cleared and invalidated. Due to the table entries being shattered, the subsequent TLB invalidation for the higher address would not then clear the TLB entries for the lower address, meaning stale TLB entries could persist. Besides it also helps in improving the performance via TLBI range operation along with reduced synchronization instructions. The time spent executing unmap_hotplug_range() improved 97% measured over a 2GB memory hot removal in KVM guest. This scheme is not applicable during vmemmap mapping tear down where memory needs to be freed and hence a TLB flush is required after clearing out page table entry. Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Closes: https://lore.kernel.org/all/aWZYXhrT6D2M-7-N@willie-the-truck/ Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-04-01Merge tag 'stm32-dt-for-7.1-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into soc/dt STM32 DT for v7.1, round 1 Highlights: ---------- - MPU: - STM32MP13: - Introduce and enable debug bus on DK board. - Enable Coresight on DK board. - Add DT overlays for DH board. - Add Wakeup capabilities on I2C nodes. - STMP32MP15: - ST: - Enable DCMI DMA chaining to improve performances. - Introduce and enable debug bus on EV and DK board. - Enable Coresight on EV and DK board. - DH: - Add DT overlays for DH board. - Phytec: - Rename "Phycore" to "phyboard-sargas" DT files and introduce SOM device tree file. - Fix and enhance current support. - STM32MP21: - Add Bsec support. - STM32MP23: - Add LTDC and LVDS support and enable display on STM32MP235F-DK board. - STM32MP25: - Enable display on STM32MP235F-DK board. * tag 'stm32-dt-for-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: (42 commits) arm64: defconfig: Enable STMicroelectronics STM32 display support arm64: dts: st: enable display support on stm32mp257f-dk board arm64: dts: st: describe power supplies for stm32mp257f-dk board arm64: dts: st: enable display support on stm32mp235f-dk board arm64: dts: st: describe power supplies for stm32mp235f-dk board arm64: dts: st: add clock-cells to syscfg node on stm32mp231 arm64: dts: st: add lvds support on stm32mp235 arm64: dts: st: add ltdc support on stm32mp235 arm64: dts: st: add ltdc support on stm32mp231 arm64: dts: st: omit unused pinctrl groups from stm32mp25 dtb files arm64: dts: st: add bootph-all in bsec node to stm32mp215f-dk arm64: dts: st: add bsec support to stm32mp21 ARM: dts: stm32: fix misalignments in nodes of stm32mp131 ARM: dts: stm32: fix misalignments in nodes of stm32mp151 arm64: dts: st: describe i2c2 / i2c8 on stm32mp235f-dk arm64: dts: st: describe i2c2 / i2c8 on stm32mp257f-dk arm64: dts: st: disable DMA usage for i2c on stm32mp257f-ev1 arm64: dts: st: add i2c2 pinmux nodes in stm32mp25-pinctrl.dtsi arm64: dts: st: update i2c nodes interrupt/wakeup-source in stm32mp231 arm64: dts: st: update i2c nodes interrupt/wakeup-source in stm32mp251 ... Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-01Merge tag 'samsung-dt-7.1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/dt Samsung DTS ARM changes for v7.1 1. New board: Exynos5250 based Google Manta (Nexus 10). 2. Few cleanups. * tag 'samsung-dt-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: dts: exyons4412: Drop duplicated I2C address/size-cells ARM: dts: exynos4210-smdkv310: Drop duplicated I2C address/size-cells ARM: dts: exynos3250: Drop duplicated I2C address/size-cells ARM: dts: exynos: Add Google Manta (Nexus 10) dt-bindings: ARM: samsung: Add Google Manta (Nexus 10) Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-01KVM: arm64: vgic-v5: Fold PPI state for all exposed PPIsSascha Bischoff
GICv5 supports up to 128 PPIs, which would introduce a large amount of overhead if all of them were actively tracked. Rather than keeping track of all 128 potential PPIs, we instead only consider the set of architected PPIs (the first 64). Moreover, we further reduce that set by only exposing a subset of the PPIs to a guest. In practice, this means that only 4 PPIs are typically exposed to a guest - the SW_PPI, PMUIRQ, and the timers. When folding the PPI state, changed bits in the active or pending were used to choose which state to sync back. However, this breaks badly for Edge interrupts when exiting the guest before it has consumed the edge. There is no change in pending state detected, and the edge is lost forever. Given the reduced set of PPIs exposed to the guest, and the issues around tracking the edges, drop the tracking of changed state, and instead iterate over the limited subset of PPIs exposed to the guest directly. This change drops the second copy of the PPI pending state used for detecting edges in the pending state, and reworks vgic_v5_fold_ppi_state() to iterate over the VM's PPI mask instead. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://patch.msgid.link/20260401162152.932243-1-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01powerpc/powernv/iommu: iommu incorrectly bypass DMA APIsGaurav Batra
In a PowerNV environment, for devices that supports DMA mask less than 64 bit but larger than 32 bits, iommu is incorrectly bypassing DMA APIs while allocating and mapping buffers for DMA operations. Devices are failing with ENOMEN during probe with the following messages amdgpu 0000:01:00.0: [drm] Detected VRAM RAM=4096M, BAR=4096M amdgpu 0000:01:00.0: [drm] RAM width 128bits GDDR5 amdgpu 0000:01:00.0: iommu: 64-bit OK but direct DMA is limited by 0 amdgpu 0000:01:00.0: dma_iommu_get_required_mask: returning bypass mask 0xfffffffffffffff amdgpu 0000:01:00.0: 4096M of VRAM memory ready amdgpu 0000:01:00.0: 32570M of GTT memory ready. amdgpu 0000:01:00.0: (-12) failed to allocate kernel bo amdgpu 0000:01:00.0: [drm] Debug VRAM access will use slowpath MM access amdgpu 0000:01:00.0: [drm] GART: num cpu pages 4096, num gpu pages 65536 amdgpu 0000:01:00.0: [drm] PCIE GART of 256M enabled (table at 0x000000F4FFF80000). amdgpu 0000:01:00.0: (-12) failed to allocate kernel bo amdgpu 0000:01:00.0: (-12) create WB bo failed amdgpu 0000:01:00.0: amdgpu_device_wb_init failed -12 amdgpu 0000:01:00.0: amdgpu_device_ip_init failed amdgpu 0000:01:00.0: Fatal error during GPU init amdgpu 0000:01:00.0: finishing device. amdgpu 0000:01:00.0: probe with driver amdgpu failed with error -12 amdgpu 0000:01:00.0: ttm finalized Fixes: 1471c517cf7d ("powerpc/iommu: bypass DMA APIs for coherent allocations for pre-mapped memory") Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reported-by: Dan Horák <dan@danny.cz> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5039 Tested-by: Dan Horak <dan@danny.cz> Closes: https://lore.kernel.org/linuxppc-dev/20260313142351.609bc4c3efe1184f64ca5f44@danny.cz/ Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com> Closes: https://lore.kernel.org/linuxppc-dev/20260313142351.609bc4c3efe1184f64ca5f44@danny.cz/ [Maddy: Fixed tags] Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260331223022.47488-1-gbatra@linux.ibm.com
2026-04-01Merge tag 'samsung-dt64-7.1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/dt Samsung DTS ARM64 changes for v7.1 1. Add initial support for Axis ARTPEC-9 SoC and Alfred board using it. Just like ARTPEC-8, this is a derivative of Samsung Exynos SoC made for Axis, sharing most or all of core SoC blocks with Samsung designs. 2. New boards: Exynos7870 based Samsung Galaxy J7 (2016) and Samsung Galaxy J5 (2017). 3. Google GS101 Pixel phone: describe all PMIC regulators and Maxim fuel-gauge. 4. ExynosAutov920: add G3D (GPU) clock controller (CMU). * tag 'samsung-dt64-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: arm64: dts: exynos8895: Move I2C address/size-cells to DTSI arm64: dts: exynos7870: Move I2C address/size-cells to DTSI arm64: dts: exynos: gs101-pixel-common: add Maxim MAX77759 fuel gauge arm64: dts: exynos: add initial support for Samsung Galaxy J5 dt-bindings: arm: samsung: add compatible for samsung-j5y17lte arm64: dts: exynosautov920: add CMU_G3D clock DT nodes arm64: dts: exynos: gs101-pixel: add all S2MPG1x regulators arm64: dts: exynos: add initial support for Samsung Galaxy J7 (2016) dt-bindings: arm: samsung: add compatible for samsung-j7xelte arm64: dts: axis: artpec9: Fix missing soc unit address arm64: dts: axis: Add ARTPEC-9 Alfred board support arm64: dts: exynos: axis: Add initial ARTPEC-9 SoC support dt-bindings: arm: axis: Add ARTPEC-9 alfred board dt-bindings: clock: Add ARTPEC-9 clock controller Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-01Merge tag 'arm-soc/for-7.1/devicetree-arm64' of ↵Arnd Bergmann
https://github.com/Broadcom/stblinux into soc/dt This pull request contains Broadcom ARM64-based SoCs Device Tree updates for 7.1, please pull the following: - Maira adds the V3D DT node to the 2712 (Raspberry Pi 5) SoC - Gergor adds the I2C controller, CSI (camera), ISP (image signal processor), fixes the pinctrl node and updates the UART10 interrupt for the RP1 sister chip to the 2712 (Raspberry Pi 5) - Rob moves the firmware and GPU to the root level to fix DTC warnings * tag 'arm-soc/for-7.1/devicetree-arm64' of https://github.com/Broadcom/stblinux: arm64: dts: broadcom: bcm2712: Move non simple-bus nodes to root level arm64: dts: broadcom: bcm2712-d-rpi-5-b: update uart10 interrupt arm64: dts: broadcom: bcm2712-d-rpi-5-b: add fixes for pinctrl/pinctrl_aon arm64: dts: broadcom: bcm2712-rpi-5-b: add pinctrl properties for csi i2cs arm64: dts: broadcom: bcm2712: add camera backend node pispbe arm64: dts: broadcom: rp1: add csi nodes arm64: dts: broadcom: rp1: add i2c controller arm64: dts: broadcom: bcm2712: Add V3D device node Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-04-01KVM: arm64: Destroy stage-2 page-table in kvm_arch_destroy_vm()Will Deacon
kvm_arch_destroy_vm() can be called on the kvm_create_vm() error path after we have failed to register the MMU notifiers for the new VM. In this case, we cannot rely on the MMU ->release() notifier to call kvm_arch_flush_shadow_all() and so the stage-2 page-table allocated in kvm_arch_init_vm() will be leaked. Explicitly destroy the stage-2 page-table in kvm_arch_destroy_vm(), so that we clean up after kvm_arch_destroy_vm() without relying on the MMU notifiers. Link: https://sashiko.dev/#/patchset/20260327140039.21228-1-will%40kernel.org?patch=12265 Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260327192758.21739-3-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Don't leave mmu->pgt dangling on kvm_init_stage2_mmu() errorWill Deacon
If kvm_init_stage2_mmu() fails to allocate 'mmu->last_vcpu_ran', it destroys the newly allocated stage-2 page-table before returning ENOMEM. Unfortunately, it also leaves a dangling pointer in 'mmu->pgt' which points at the freed 'kvm_pgtable' structure. This is likely to confuse the kvm_vcpu_init_nested() failure path which can double-free the structure if it finds it via kvm_free_stage2_pgd(). Ensure that the dangling 'mmu->pgt' pointer is cleared when returning an error from kvm_init_stage2_mmu(). Link: https://sashiko.dev/#/patchset/20260327140039.21228-1-will%40kernel.org?patch=12265 Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260327192758.21739-2-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Prevent the host from using an smc with imm16 != 0Sebastian Ene
The ARM Service Calling Convention (SMCCC) specifies that the function identifier and parameters should be passed in registers, leaving the 16-bit immediate field un-handled in pKVM when an SMC instruction is trapped. Since the HVC is a private interface between EL2 and the host, enforce the host kernel running under pKVM to use an immediate value of 0 only when using SMCs to make it clear for non-compliant software talking to Trustzone that we only use SMCCC. Signed-off-by: Sebastian Ene <sebastianene@google.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260330105441.3226904-1-sebastianene@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't supportedMarc Zyngier
Although the AArch32 ID regs are architecturally UNKNOWN when AArch32 isn't supported at any EL, KVM makes a point in making them RAZ. Therefore, advertising GICv3 in ID_PFR1_EL1 must be gated on AArch32 being supported at least at EL0. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE") Reported-by: Mark Brown <broonie@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20260401103611.357092-16-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handlingMarc Zyngier
While we now compute ID_AA64PFR2_EL1 to a glorious 0, we never use that data and instead return the 0 that corresponds to an allocated idreg. Not a big deal, but we might as well be consistent. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 5aefaf11f9af5 ("KVM: arm64: gic: Hide GICv5 for protected guests") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-15-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Move GICv5 timer PPI validation into timer_irqs_are_valid()Marc Zyngier
Userspace can set the timer PPI numbers way before a GIC has been created, leading to odd behaviours on GICv5 as we'd accept non architectural PPI numbers. Move the v5 check into timer_irqs_are_valid(), which aligns the behaviour with the pre-v5 GICs, and is also guaranteed to run only once a GIC has been configured. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-14-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer()Marc Zyngier
The vgic-v5 code added some evaluations of the timers in a helper funtion (kvm_cpu_has_pending_timer()) that is called to determine whether the vcpu can wake-up. But looking at the timer there is wrong: - we want to see timers that are signalling an interrupt to the vcpu, and not just that have a pending interrupt - we already have kvm_arch_vcpu_runnable() that evaluates the state of interrupts - kvm_cpu_has_pending_timer() really is about WFIT, as the timeout does not generate an interrupt, and is therefore distinct from the point above As a consequence, revert these changes and teach vgic_v5_has_pending_ppi() about checking for pending HW interrupts instead. Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-13-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Kill arch_timer_context::direct fieldMarc Zyngier
The newly introduced arch_timer_context::direct field is a bit pointless, as it is always set on timers that are... err... direct, while we already have a way to get to that by doing a get_map() operation. Additionally, this field is: - only set when get_map() is called - never cleared and the single point where it is actually checked doesn't call get_map() at all. At this stage, it is probably better to just kill it, and rely on get_map() to give us the correct information. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-12-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Correctly set dist->ready once initialisedMarc Zyngier
kvm_vgic_map_resources() targetting a v5 model results in vgic->dist_ready never being set. This doesn't result in anything really bad, only some more heavy locking as we go and re-init something for no good reason. Rejig the code to correctly set the ready flag in all non-failing cases. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: f4d37c7c35769 ("KVM: arm64: gic-v5: Create and initialise vgic_v5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-11-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Make the effective priority mask a strict limitMarc Zyngier
The way the effective priority mask is compared to the priority of an interrupt to decide whether to wake-up or not, is slightly odd, and breaks at the limits. This could result in spurious wake-ups that are undesirable. Make the computed priority mask comparison a strict inequality, so that interrupts that have the same priority as the mask are not signalled. Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-10-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined behavioursMarc Zyngier
Passing a u64 to __builtin_ctz() is odd, and requires some digging to figure out why this construct is indeed safe as long as the HW is correct. But it is much easier to make it clear to the compiler by casting the u64 into an intermediate u32, and be done with the UD. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-9-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2Marc Zyngier
While it is perfectly correct to leave the pending state of a level interrupt as is when queuing it (it is, after all, only driven by the line), edge pending state must be transfered, as nothing will lower it. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 4d591252bacb2 ("KVM: arm64: gic-v5: Implement PPI interrupt injection") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-8-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Hold config_lock while finalizing GICv5 PPIsMarc Zyngier
Finalizing the PPI state is done without holding any lock, which means that two vcpus can race against each other and have one zeroing the state while another one is setting it, or even maybe using it. Fixing this is done by: - holding the config lock while performing the initialisation - checking if SW_PPI has already been advertised, meaning that we have already completed the initialisation once Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 8f1fbe2fd2792 ("KVM: arm64: gic-v5: Finalize GICv5 PPIs and generate mask") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-7-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Account for RESx bits in __compute_fgt()Marc Zyngier
When computing Fine Grained Traps, it is preferable to account for the reserved bits. The HW will most probably ignore them, unless the bits have been repurposed to do something else. Use caution, and fold our view of the reserved bits in, Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: c259d763e6b09 ("KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260401103611.357092-6-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Fix writeable mask for ID_AA64PFR2_EL1Marc Zyngier
The writeable mask for fields in ID_AA64PFR2_EL1 has been accidentally inverted, which isn't a very good idea. Restore the expected polarity. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-5-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01arm64: Fix field references for ICH_PPI_DVIR[01]_EL2Marc Zyngier
The ICH_PPI_DVIR[01]_EL2 registers should refer to the ICH_PPI_DVIRx_EL2 fields, instead of ICH_PPI_DVIx_EL2. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 2808a8337078f ("arm64/sysreg: Add remaining GICv5 ICC_ & ICH_ sysregs for KVM support") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Don't skip per-vcpu NV initialisationMarc Zyngier
Some GICv5-related rework have resulted in the NV sanitisation of registers being skipped for secondary vcpus, which is a pretty bad idea. Hoist the NV init early so that it is always executed. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: cbd8c958be54a ("KVM: arm64: Return early from kvm_finalize_sys_regs() if guest has run") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize timeMarc Zyngier
Although we are OK with rewriting idregs at finalize time, resetting the guest's cpuif (GICv3) or redistributor (GICv3) addresses once we start running the guest is a pretty bad idea. Move back this initialisation to vgic creation time. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE") Link: https://patch.msgid.link/20260323174713.3183111-1-maz@kernel.org Link: https://patch.msgid.link/20260401103611.357092-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Add chassis-typePaul Sajna
The sdm845-lg devices are all phones, therefore handset chassis Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-12-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg: Add wifi nodesPaul Sajna
Wi-Fi now works with this patch, relevant firmware and qcom,snoc-host-cap-skip-quirk qcom,snoc-host-cap-skip-quirk has not been approved/merged in mainline, so it is not included here. ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40030001 ath10k_snoc 18800000.wifi: qmi fw_version 0x20060285 fw_build_timestamp 2020-10-12 23:35 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c4-00645-QCAHLSWMTPLZ-1.336037.2 ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000 ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 1 tracing 0 dfs 0 testmode 0 ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790 ath10k_snoc 18800000.wifi: htt-ver 3.83 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1 ath10k_snoc 18800000.wifi: invalid MAC address; choosing random Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-11-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyln: Add display panelPaul Sajna
Also include other supporting msm drm nodes, gpio and backlight Co-developed-by: Amir Dahan <system64fumo@tuta.io> Signed-off-by: Amir Dahan <system64fumo@tuta.io> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-10-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyln: Add lab/ibbPaul Sajna
These regulators are required for the LCD Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-9-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Add LEDsAmir Dahan
Add the multicolor status LED in the phone's notch. Signed-off-by: Amir Dahan <system64fumo@tuta.io> Reviewed-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-8-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyln: Add battery and chargerChristopher Brown
Values based on lineageos kernel https://github.com/LineageOS/android_kernel_lge_sdm845/blob/lineage-22.2/arch/arm64/boot/dts/lge/sdm845-battery/LGE_BLT39_LGC_3000mAh.dtsi Signed-off-by: Christopher Brown <crispybrown@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-7-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg: Add uarts and BluetoothPaul Sajna
uart9 is debug serial on USB SBU1/2 UART RX is SBU1 and UART TX is SBU2 of the USB-C port). 1.8V Logic Level Tested using pololu usb07a https://www.pololu.com/product/2585 and CH340 USB-UART uart6 is bluetooth Bluetooth: hci0: setting up wcn399x Bluetooth: hci0: QCA Product ID :0x0000000a Bluetooth: hci0: QCA SOC Version :0x40010214 Bluetooth: hci0: QCA ROM Version :0x00000201 Bluetooth: hci0: QCA Patch Version:0x00000001 Bluetooth: hci0: QCA controller version 0x02140201 Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv Bluetooth: hci0: QCA Downloading qca/judyln/crnv21.bin Bluetooth: hci0: QCA setup on UART is completed Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-6-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Enable qups and their dma controllersPaul Sajna
Qualcomm serial communicators required for i2c, serial, and spi Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-5-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Enable venusPaul Sajna
Qualcomm video en/de-coder Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-4-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyp: Define firmware paths for judypPaul Sajna
For consistency with judyln and new naming scheme for firmware Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-3-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-judyln: Add firmware nodes, change pathPaul Sajna
Add paths for Qualcomm firmware, including: ipa, modem, venus, gpu GPU and bluetooth are confirmed working, others may need more testing/fixes But regardless they will need the firmware paths specified here and firmware added upstream before they will work, so might as well get started on it now. Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-2-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-01arm64: dts: qcom: sdm845-lg-common: Sort nodes and propertiesPaul Sajna
Improve adherance to style guidelines below: https://docs.kernel.org/devicetree/bindings/dts-coding-style.html Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Paul Sajna <sajattack@postmarketos.org> Link: https://lore.kernel.org/r/20260331-judyln-dts-v7-1-87217b15fefb@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-11 15:41:40 +0000