summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2 daysarm64: kexec: initialize kexec_buf struct in load_other_segments()Breno Leitao1-1/+1
commit 04d3cd43700a2d0fe4bfb1012a8ec7f2e34a3507 upstream. Patch series "kexec: Fix invalid field access". The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. An initial fix was already landed for arm64[0], and this patchset fixes the problem on the remaining arm64 code and on riscv, as raised by Mark. Discussions about this problem could be found at[1][2]. This patch (of 3): The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-0-1df9882bb01a@debian.org Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-1-1df9882bb01a@debian.org Link: https://lore.kernel.org/all/20250826180742.f2471131255ec1c43683ea07@linux-foundation.org/ [0] Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnzadw@c67o7njgdgm3/ [1] Link: https://lore.kernel.org/all/20250826-akpm-v1-1-3c831f0e3799@debian.org/ [2] Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Baoquan He <bhe@redhat.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Coiby Xu <coxu@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Will Deacon <will@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysarm64: ftrace: fix unreachable PLT for ftrace_caller in init_module with ↵panfan5-4/+34
CONFIG_DYNAMIC_FTRACE commit a7ed7b9d0ebb038db9963d574da0311cab0b666a upstream. On arm64, it has been possible for a module's sections to be placed more than 128M away from each other since commit: commit 3e35d303ab7d ("arm64: module: rework module VA range selection") Due to this, an ftrace callsite in a module's .init.text section can be out of branch range for the module's ftrace PLT entry (in the module's .text section). Any attempt to enable tracing of that callsite will result in a BRK being patched into the callsite, resulting in a fatal exception when the callsite is later executed. Fix this by adding an additional trampoline for .init.text, which will be within range. No additional trampolines are necessary due to the way a given module's executable sections are packed together. Any executable section beginning with ".init" will be placed in MOD_INIT_TEXT, and any other executable section, including those beginning with ".exit", will be placed in MOD_TEXT. Fixes: 3e35d303ab7d ("arm64: module: rework module VA range selection") Cc: <stable@vger.kernel.org> # 6.5.x Signed-off-by: panfan <panfan@qti.qualcomm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250905032236.3220885-1-panfan@qti.qualcomm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 daysarm64: dts: rockchip: Add supplies for eMMC on rk3588-orangepi-5Chen-Yu Tsai1-0/+2
[ Upstream commit 2dea24df234940b27d378f786933dc10f33de6b8 ] The eMMC description is missing both vmmc and vqmmc supplies. Add them to complete the description. Fixes: 236d225e1ee7 ("arm64: dts: rockchip: Add board device tree for rk3588-orangepi-5-plus") Fixes: ea63f4666e48 ("arm64: dts: rockchip: refactor common rk3588-orangepi-5.dtsi") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20250821052939.1869171-1-wens@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
12 daysarm64: dts: rockchip: Fix the headphone detection on the orangepi 5 plusMaud Spierings1-1/+1
[ Upstream commit 8976583832579fe7e450034d6143d74d9f8c8608 ] The logic of the headphone detect pin seems to be inverted, with this change headphones actually output sound when plugged in. Verified by checking /sys/kernel/debug/gpio and by listening. Fixes: 236d225e1ee7 ("arm64: dts: rockchip: Add board device tree for rk3588-orangepi-5-plus") Signed-off-by: Maud Spierings <maud_spierings@hotmail.com> Reviewed-by: Ondřej Jirman <megi@xff.cz> Link: https://lore.kernel.org/r/20250823-orangepi5-v1-1-ae77dd0e06d7@hotmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
12 daysarm64: dts: imx8mp: Fix missing microSD slot vqmmc on Data Modul i.MX8M Plus ↵Marek Vasut1-0/+1
eDM SBC [ Upstream commit 80733306290f6d2e05f0632e5d3e98cd16105c3c ] Add missing microSD slot vqmmc-supply property, otherwise the kernel might shut down LDO5 regulator and that would power off the microSD card slot, possibly while it is in use. Add the property to make sure the kernel is aware of the LDO5 regulator which supplies the microSD slot and keeps the LDO5 enabled. Fixes: 562d222f23f0 ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
12 daysarm64: dts: imx8mp: Fix missing microSD slot vqmmc on DH electronics i.MX8M ↵Marek Vasut1-0/+1
Plus DHCOM [ Upstream commit c53cf8ce3bfe1309cb4fd4d74c5be27c26a86e52 ] Add missing microSD slot vqmmc-supply property, otherwise the kernel might shut down LDO5 regulator and that would power off the microSD card slot, possibly while it is in use. Add the property to make sure the kernel is aware of the LDO5 regulator which supplies the microSD slot and keeps the LDO5 enabled. Fixes: 8d6712695bc8 ("arm64: dts: imx8mp: Add support for DH electronics i.MX8M Plus DHCOM and PDK2") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
12 daysarm64: dts: imx8mp-tqma8mpql: fix LDO5 power offMarkus Niebel3-12/+36
[ Upstream commit 5245dc5ff9b1f6c02ef948f623432805ea148fca ] Fix SD card removal caused by automatic LDO5 power off after boot: LDO5: disabling mmc1: card 59b4 removed EXT4-fs (mmcblk1p2): shut down requested (2) Aborting journal on device mmcblk1p2-8. JBD2: I/O error when updating journal superblock for mmcblk1p2-8. To prevent this, add vqmmc regulator for USDHC, using a GPIO-controlled regulator that is supplied by LDO5. Since this is implemented on SoM but used on baseboards with SD-card interface, implement the functionality on SoM part and optionally enable it on baseboards if needed. Fixes: 418d1d840e42 ("arm64: dts: freescale: add initial device tree for TQMa8MPQL with i.MX8MP") Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
12 daysarm64: dts: rockchip: Add vcc-supply to SPI flash on rk3399-pinebook-proPeter Robinson1-0/+1
[ Upstream commit d1f9c497618dece06a00e0b2995ed6b38fafe6b5 ] As described in the pinebookpro_v2.1_mainboard_schematic.pdf page 10, he SPI Flash's VCC connector is connected to VCC_3V0 power source. This fixes the following warning: spi-nor spi1.0: supply vcc not found, using dummy regulator Fixes: 5a65505a69884 ("arm64: dts: rockchip: Add initial support for Pinebook Pro") Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20250730102129.224468-1-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
12 daysarm64: dts: rockchip: mark eeprom as read-only for Radxa E52CChukun Pan1-0/+1
[ Upstream commit f18c9e79bbe65627805fff6aac3ea96b6b55b53d ] The eeprom on the Radxa E52C SBC contains manufacturer data such as the mac address, so it should be marked as read-only. Fixes: 9be4171219b6 ("arm64: dts: rockchip: Add Radxa E52C") Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20250810100020.445053-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-09-04arm64: mm: Fix CFI failure due to kpti_ng_pgd_alloc function signatureKees Cook3-9/+10
commit ceca927c86e6f72f72d45487a34368bc9509431d upstream. Seen during KPTI initialization: CFI failure at create_kpti_ng_temp_pgd+0x124/0xce8 (target: kpti_ng_pgd_alloc+0x0/0x14; expected type: 0xd61b88b6) The call site is alloc_init_pud() at arch/arm64/mm/mmu.c: pud_phys = pgtable_alloc(TABLE_PUD); alloc_init_pud() has the prototype: static void alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end, phys_addr_t phys, pgprot_t prot, phys_addr_t (*pgtable_alloc)(enum pgtable_type), int flags) where the pgtable_alloc() prototype is declared. The target (kpti_ng_pgd_alloc) is used in arch/arm64/kernel/cpufeature.c: create_kpti_ng_temp_pgd(kpti_ng_temp_pgd, __pa(alloc), KPTI_NG_TEMP_VA, PAGE_SIZE, PAGE_KERNEL, kpti_ng_pgd_alloc, 0); which is an alias for __create_pgd_mapping_locked() with prototype: extern __alias(__create_pgd_mapping_locked) void create_kpti_ng_temp_pgd(pgd_t *pgdir, phys_addr_t phys, unsigned long virt, phys_addr_t size, pgprot_t prot, phys_addr_t (*pgtable_alloc)(enum pgtable_type), int flags); __create_pgd_mapping_locked() passes the function pointer down: __create_pgd_mapping_locked() -> alloc_init_p4d() -> alloc_init_pud() But the target function (kpti_ng_pgd_alloc) has the wrong signature: static phys_addr_t __init kpti_ng_pgd_alloc(int shift); The "int" should be "enum pgtable_type". To make "enum pgtable_type" available to cpufeature.c, move enum pgtable_type definition from arch/arm64/mm/mmu.c to arch/arm64/include/asm/mmu.h. Adjust kpti_ng_pgd_alloc to use "enum pgtable_type" instead of "int". The function behavior remains identical (parameter is unused). Fixes: c64f46ee1377 ("arm64: mm: use enum to identify pgtable level instead of *_SHIFT") Cc: <stable@vger.kernel.org> # 6.16.x Signed-off-by: Kees Cook <kees@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250829190721.it.373-kees@kernel.org Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: rockchip: Remove workaround that prevented Turing RK1 GPU power ↵Sam Edwards1-11/+0
regulator control commit de5b39d16318f9345f1ba7c1b684ba0c1cb6fdad upstream. The RK3588 GPU power domain cannot be activated unless the external power regulator is already on. When GPU support was added to this DT, we had no way to represent this requirement, so `regulator-always-on` was added to the `vdd_gpu_s0` regulator in order to ensure stability. A later patch series (see "Fixes:" commit) resolved this shortcoming, but that commit left the workaround -- and rendered the comment above it no longer correct. Remove the workaround to allow the GPU power regulator to power off, now that the DT includes the necessary information to power it back on correctly. Fixes: f94500eb7328b ("arm64: dts: rockchip: Add GPU power domain regulator dependency for RK3588") Signed-off-by: Sam Edwards <CFSworks@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250608184855.130206-1-CFSworks@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: ti: k3-am62-verdin: Enable pull-ups on I2C busesEmanuele Ghidoli1-6/+6
commit bdf4252f736cc1d2a8e3e633c70fe6c728f0756e upstream. Enable internal bias pull-ups on the SoC-side I2C buses that do not have external pull resistors populated on the SoM. This ensures proper default line levels. Cc: stable@vger.kernel.org Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20250528110741.262336-1-ghidoliemanuele@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: exynos7870-on7xelte: reduce memory ranges to base amountKaustabh Chakraborty1-1/+1
commit 2bdfa35a7bb6e3a319e7a290baa44720bc96e5e4 upstream. The device is available in multiple variants with differing RAM capacities. The memory range defined in the 0x80000000 bank exceeds the address range of the memory controller, which eventually leads to ARM SError crashes. Reduce the bank size to a value which is available to all devices. The bootloader must be responsible for identifying the RAM capacity and editing the memory node accordingly. Fixes: d6f3a7f91fdb ("arm64: dts: exynos: add initial devicetree support for exynos7870") Cc: stable@vger.kernel.org # v6.16 Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Link: https://lore.kernel.org/r/20250626-exynos7870-dts-fixes-v1-2-349987874d9a@disroot.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board fileJudith Mendez3-24/+48
commit a0b8da04153eb61cc2eaeeea5cc404e91e557f6b upstream. This moves pinmux child nodes for sdhci0 node from k3-am62x-sk-common to each top level board file. This is needed since we require internal pullups for AM62x SK and not for AM62 LP SK since it has external pullups on DATA 1-7. Internal pulls are required for AM62 SK as per JESD84 spec recommendation to prevent unconnected lines floating. Fixes: d19a66ae488a ("arm64: dts: ti: k3-am625-sk: Enable on board peripherals") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20250707190830.3951619-1-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: ti: k3-am62a7-sk: fix pinmux for main_uart1Hong Guan1-2/+2
commit 8e44ac61abaae56fc6eb537a04ed78b458c5b984 upstream. main_uart1 reserved for TIFS firmware traces is routed to the onboard FT4232 via a FET switch which is connected to pin A21 and B21 of the SoC and not E17 and C17. Fix it. Fixes: cf39ff15cc01a ("arm64: dts: ti: k3-am62a7-sk: Describe main_uart1 and wkup_uart") Cc: stable@vger.kernel.org Signed-off-by: Hong Guan <hguan@ti.com> [bb@ti.com: expanded commit message] Signed-off-by: Bryan Brattlof <bb@ti.com> Link: https://lore.kernel.org/r/20250707-uart-fixes-v1-1-8164147218b0@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: exynos: gs101: ufs: add dma-coherent propertyPeter Griffin1-0/+1
commit 4292564c71cffd8094abcc52dd4840870d05cd30 upstream. ufs-exynos driver configures the sysreg shareability as cacheable for gs101 so we need to set the dma-coherent property so the descriptors are also allocated cacheable. This fixes the UFS stability issues we have seen with the upstream UFS driver on gs101. Fixes: 4c65d7054b4c ("arm64: dts: exynos: gs101: Add ufs and ufs-phy dt nodes") Cc: stable@vger.kernel.org Suggested-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Will McVicker <willmcvicker@google.com> Tested-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250314-ufs-dma-coherent-v1-1-bdf9f9be2919@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: rockchip: Enable HDMI PHY clk provider on rk3576Cristian Ciocaltea1-0/+1
commit aba7987a536cee67fb0cb724099096fd8f8f5350 upstream. As with the RK3588 SoC, the HDMI PHY PLL on RK3576 can be used as a more accurate pixel clock source for VOP2, which is actually mandatory to ensure proper support for display modes handling. Add the missing #clock-cells property to allow using the clock provider functionality of HDMI PHY. Fixes: ad0ea230ab2a ("arm64: dts: rockchip: Add hdmi for rk3576") Cc: stable@vger.kernel.org Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250612-rk3576-hdmitx-fix-v1-2-4b11007d8675@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: rockchip: Add HDMI PHY PLL clock source to VOP2 on rk3576Cristian Ciocaltea1-2/+4
commit 4ab8b8ac952fb08d03655e1da0cfee07589e428f upstream. Since commit c871a311edf0 ("phy: rockchip: samsung-hdptx: Setup TMDS char rate via phy_configure_opts_hdmi"), the workaround of passing the rate from DW HDMI QP bridge driver via phy_set_bus_width() became partially broken, as it cannot reliably handle mode switches anymore. Attempting to fix this up at PHY level would not only introduce additional hacks, but it would also fail to adequately resolve the display issues that are a consequence of the system CRU limitations. Instead, proceed with the solution already implemented for RK3588: make use of the HDMI PHY PLL as a better suited DCLK source for VOP2. This will not only address the aforementioned problem, but it should also facilitate the proper operation of display modes up to 4K@60Hz. It's worth noting that anything above 4K@30Hz still requires high TMDS clock ratio and scrambling support, which hasn't been mainlined yet. Fixes: d74b842cab08 ("arm64: dts: rockchip: Add vop for rk3576") Cc: stable@vger.kernel.org Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Tested-By: Detlev Casanova <detlev.casanova@collabora.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250612-rk3576-hdmitx-fix-v1-3-4b11007d8675@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: exynos7870: add quirk to disable USB2 LPM in gadget modeKaustabh Chakraborty1-0/+1
commit e9355e894aebcbeacffd284644749190cc5f33a4 upstream. In gadget mode, USB connections are sluggish. The device won't send packets to the host unless the host sends packets to the device. For instance, SSH-ing through the USB network would apparently not work unless you're flood-pinging the device's IP. Add the property snps,usb2-gadget-lpm-disable to the dwc3 node, which seems to solve this issue. Fixes: d6f3a7f91fdb ("arm64: dts: exynos: add initial devicetree support for exynos7870") Cc: stable@vger.kernel.org # v6.16 Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Link: https://lore.kernel.org/r/20250626-exynos7870-dts-fixes-v1-1-349987874d9a@disroot.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by defaultAlexander Sverdlin1-3/+12
commit 5b272127884bded21576a6ddceca13725a351c63 upstream. Switch Schmitt Trigger functions for PIN_INPUT* macros by default. This is HW PoR configuration, the slew rate requirements without ST enabled are pretty tough for these devices. We've noticed spurious GPIO interrupts even with noise-free edges but not meeting slew rate requirements (3.3E+6 V/s for 3.3v LVCMOS). It's not obvious why one might want to disable the PoR-enabled ST on any pin. Just enable it by default. As it's not possible to provide OR-able macros to disable the ST, shall anyone require it, provide a set of new macros with _NOST suffix. Fixes: fe49f2d776f7 ("arm64: dts: ti: Use local header for pinctrl register values") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20250701105437.3539924-1-alexander.sverdlin@siemens.com [vigneshr@ti.com: Add Fixes tag] Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: exynos7870-j6lte: reduce memory ranges to base amountKaustabh Chakraborty1-1/+1
commit 49a27c6c392dec46c826ee586f7ec8973acaeed7 upstream. The device is available in multiple variants with differing RAM capacities. The memory range defined in the 0x80000000 bank exceeds the address range of the memory controller, which eventually leads to ARM SError crashes. Reduce the bank size to a value which is available to all devices. The bootloader must be responsible for identifying the RAM capacity and editing the memory node accordingly. Fixes: d6f3a7f91fdb ("arm64: dts: exynos: add initial devicetree support for exynos7870") Cc: stable@vger.kernel.org # v6.16 Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Link: https://lore.kernel.org/r/20250626-exynos7870-dts-fixes-v1-3-349987874d9a@disroot.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: ti: k3-am62-main: Remove eMMC High Speed DDR supportJudith Mendez1-1/+0
commit 265f70af805f33a0dfc90f50cc0f116f702c3811 upstream. For eMMC, High Speed DDR mode is not supported [0], so remove mmc-ddr-1_8v flag which adds the capability. [0] https://www.ti.com/lit/gpn/am625 Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20250707191250.3953990-1-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28arm64: dts: apple: t8012-j132: Include touchbar framebuffer nodeNick Chan1-0/+1
commit ef68a0e1087882850628000f28078e1c4df917ee upstream. Apple T2 MacBookPro15,2 (j132) has a touchbar so include the framebuffer node. Cc: stable@vger.kernel.org Fixes: 4efbcb623e9bc ("arm64: dts: apple: Add T2 devices") Signed-off-by: Nick Chan <towinchenmi@gmail.com> Link: https://lore.kernel.org/stable/20250620-j132-fb-v1-1-bc6937baf0b9%40gmail.com Link: https://lore.kernel.org/r/20250620-j132-fb-v2-1-65f100182085@gmail.com Signed-off-by: Sven Peter <sven@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contextsEric Biggers1-1/+2
commit eec76ea5a7213c48529a46eed1b343e5cee3aaab upstream. Restore the SIMD usability check that was removed by commit a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface"). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. Fixes: a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface") Cc: stable@vger.kernel.org Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250706231100.176113-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-20mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()Anshuman Khandual1-3/+0
commit 59305202c67fea50378dcad0cc199dbc13a0e99a upstream. Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths. Link: https://lkml.kernel.org/r/20250620052427.2092093-1-anshuman.khandual@arm.com Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Dev Jain <dev.jain@arm.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> [s390] Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-20arm64: stacktrace: Check kretprobe_find_ret_addr() return valueMark Rutland1-0/+2
[ Upstream commit beecfd6a88a675e20987e70ec532ba734b230fa4 ] If kretprobe_find_ret_addr() fails to find the original return address, it returns 0. Check for this case so that a reliable stacktrace won't silently ignore it. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andrea della Porta <andrea.porta@suse.com> Cc: Breno Leitao <leitao@debian.org> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Miroslav Benes <mbenes@suse.cz> Cc: Petr Mladek <pmladek@suse.com> Cc: Song Liu <song@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-and-tested-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20250521111000.2237470-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20ACPI: Suppress misleading SPCR console message when SPCR table is absentLi Chen1-3/+7
[ Upstream commit bad3fa2fb9206f4dcec6ddef094ec2fbf6e8dcb2 ] The kernel currently alway prints: "Use ACPI SPCR as default console: No/Yes " even on systems that lack an SPCR table. This can mislead users into thinking the SPCR table exists on the machines without SPCR. With this change, the "Yes" is only printed if the SPCR table is present, parsed and !param_acpi_nospcr. This avoids user confusion on SPCR-less systems. Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Acked-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/20250620131309.126555-3-me@linux.beauty Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20arm64: Mark kernel as tainted on SAE and SError panicBreno Leitao2-0/+2
[ Upstream commit d7ce7e3a84642aadf7c4787f7ec4f58eb163d129 ] Set TAINT_MACHINE_CHECK when SError or Synchronous External Abort (SEA) interrupts trigger a panic to flag potential hardware faults. This tainting mechanism aids in debugging and enables correlation of hardware-related crashes in large-scale deployments. This change aligns with similar patches[1] that mark machine check events when the system crashes due to hardware errors. Link: https://lore.kernel.org/all/20250702-add_tain-v1-1-9187b10914b9@debian.org/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250716-vmcore_hw_error-v2-1-f187f7d62aba@debian.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20arm64: Handle KCOV __init vs inline mismatchesKees Cook1-1/+1
[ Upstream commit 65c430906efffee9bd7551d474f01a6b1197df90 ] GCC appears to have kind of fragile inlining heuristics, in the sense that it can change whether or not it inlines something based on optimizations. It looks like the kcov instrumentation being added (or in this case, removed) from a function changes the optimization results, and some functions marked "inline" are _not_ inlined. In that case, we end up with __init code calling a function not marked __init, and we get the build warnings I'm trying to eliminate in the coming patch that adds __no_sanitize_coverage to __init functions: WARNING: modpost: vmlinux: section mismatch in reference: acpi_get_enable_method+0x1c (section: .text.unlikely) -> acpi_psci_present (section: .init.text) This problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it), but we've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on. For arm64 this requires forcing one ACPI function to be inlined with __always_inline. Link: https://lore.kernel.org/r/20250724055029.3623499-1-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-20arm64: dts: ti: k3-j722s-evm: Fix USB gpio-hog level for Type-CSiddharth Vadapalli1-1/+1
commit 65ba2a6e77e9e5c843a591055789050e77b5c65e upstream. According to the "GPIO Expander Map / Table" section of the J722S EVM Schematic within the Evaluation Module Design Files package [0], the GPIO Pin P05 located on the GPIO Expander 1 (I2C0/0x23) has to be pulled down to select the Type-C interface. Since commit under Fixes claims to enable the Type-C interface, update the property within "p05-hog" from "output-high" to "output-low", thereby switching from the Type-A interface to the Type-C interface. [0]: https://www.ti.com/lit/zip/sprr495 Cc: stable@vger.kernel.org Fixes: 485705df5d5f ("arm64: dts: ti: k3-j722s: Enable PCIe and USB support on J722S-EVM") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20250623100657.4082031-1-s-vadapalli@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-15KVM: arm64: Filter out HCR_EL2 bits when running in hypervisor contextMarc Zyngier1-2/+12
commit 303084ad12767db64c84ba8fcd0450aec38c8534 upstream. Most HCR_EL2 bits are not supposed to affect EL2 at all, but only the guest. However, we gladly merge these bits with the host's HCR_EL2 configuration, irrespective of entering L1 or L2. This leads to some funky behaviour, such as L1 trying to inject a virtual SError for L2, and getting a taste of its own medecine. Not quite what the architecture anticipated. In the end, the only bits that matter are those we have defined as invariants, either because we've made them RESx (E2H, HCD...), or that we actively refuse to merge because the mess with KVM's own logic. Use the sanitisation infrastructure to get the RES1 bits, and let things rip in a safer way. Fixes: 04ab519bb86df ("KVM: arm64: nv: Configure HCR_EL2 for FEAT_NV2") Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250721101955.535159-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-15KVM: arm64: Check for SYSREGS_ON_CPU before accessing the CPU stateMarc Zyngier2-2/+8
commit c6e35dff58d348c1a9489e9b3b62b3721e62631d upstream. Mark Brown reports that since we commit to making exceptions visible without the vcpu being loaded, the external abort selftest fails. Upon investigation, it turns out that the code that makes registers affected by an exception visible to the guest is completely broken on VHE, as we don't check whether the system registers are loaded on the CPU at this point. We managed to get away with this so far, but that's obviously as bad as it gets, Add the required checksm and document the absolute need to check for the SYSREGS_ON_CPU flag before calling into any of the __vcpu_write_sys_reg_to_cpu()__vcpu_read_sys_reg_from_cpu() helpers. Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/18535df8-e647-4643-af9a-bb780af03a70@sirena.org.uk Link: https://lore.kernel.org/r/20250720102229.179114-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-15bpf, arm64: Fix fp initialization for exception boundaryPuranjay Mohan1-0/+1
[ Upstream commit b114fcee766d5101eada1aca7bb5fd0a86c89b35 ] In the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPF program, find_used_callee_regs() is not called because for a program acting as exception boundary, all callee saved registers are saved. find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FP being used in any of the instructions. For programs acting as exception boundary, ctx->fp_used remains false even if frame pointer is used by the program and therefore, FP is not set-up for such programs in the prologue. This can cause the kernel to crash due to a pagefault. Fix it by setting ctx->fp_used = true for exception boundary programs as fp is always saved in such programs. Fixes: 5d4fa9ec5643 ("bpf, arm64: Avoid blindly saving/restoring all callee-saved registers") Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/20250722133410.54161-2-puranjay@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64/gcs: task_gcs_el0_enable() should use passed taskJeremy Linton2-4/+4
[ Upstream commit cbbcfb94c55c02a8c4ce52b5da0770b5591a314c ] Mark Rutland noticed that the task parameter is ignored and 'current' is being used instead. Since this is usually what its passed, it hasn't yet been causing problems but likely will as the code gets more testing. But, once this is fixed, it creates a new bug in copy_thread_gcs() since the gcs_el_mode isn't yet set for the task before its being checked. Move gcs_alloc_thread_stack() after the new task's gcs_el0_mode initialization to avoid this. Fixes: fc84bc5378a8 ("arm64/gcs: Context switch GCS state for EL0") Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250719043740.4548-2-jeremy.linton@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: fix unnecessary rebuilding when CONFIG_DEBUG_EFI=yMasahiro Yamada1-1/+1
[ Upstream commit 344b6580472451390d070c65c27f59716a1deecb ] When CONFIG_DEBUG_EFI is enabled, some objects are needlessly rebuilt. [Steps to reproduce] Enable CONFIG_DEBUG_EFI and run 'make' twice in a clean source tree. On the second run, arch/arm64/kernel/head.o is rebuilt even though no files have changed. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- clean $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- [ snip ] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CALL scripts/checksyscalls.sh AS arch/arm64/kernel/head.o AR arch/arm64/kernel/built-in.a AR arch/arm64/built-in.a AR built-in.a [ snip ] The issue is caused by the use of the $(realpath ...) function. At the time arch/arm64/kernel/Makefile is parsed on the first run, $(objtree)/vmlinux does not exist. As a result, $(realpath $(objtree)/vmlinux) expands to an empty string. On the second run of Make, $(objtree)/vmlinux already exists, so $(realpath $(objtree)/vmlinux) expands to the absolute path of vmlinux. However, this change in the command line causes arch/arm64/kernel/head.o to be rebuilt. To address this issue, use $(abspath ...) instead, which does not require the file to exist. While $(abspath ...) does not resolve symlinks, this should be fine from a debugging perspective. The GNU Make manual [1] clearly explains the difference between the two: $(realpath names...) For each file name in names return the canonical absolute name. A canonical name does not contain any . or .. components, nor any repeated path separators (/) or symlinks. In case of a failure the empty string is returned. Consult the realpath(3) documentation for a list of possible failure causes. $(abspath namees...) For each file name in names return an absolute name that does not contain any . or .. components, nor any repeated path separators (/). Note that, in contrast to realpath function, abspath does not resolve symlinks and does not require the file names to refer to an existing file or directory. Use the wildcard function to test for existence. The same problem exists in drivers/firmware/efi/libstub/Makefile.zboot. On the first run of Make, $(obj)/vmlinuz.efi.elf does not exist when the Makefile is parsed, so -DZBOOT_EFI_PATH is set to an empty string. Replace $(realpath ...) with $(abspath ...) there as well. [1]: https://www.gnu.org/software/make/manual/make.html#File-Name-Functions Fixes: 757b435aaabe ("efi: arm64: Add vmlinux debug link to the Image binary") Fixes: a050910972bb ("efi/libstub: implement generic EFI zboot") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250625125555.2504734-1-masahiroy@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: Fix UART DMA support for RK3528Jonas Karlman1-8/+8
[ Upstream commit ae019f0bdfbef3e0671e7b954321e92fc24c7e54 ] Trying to use UART2 DMA for Bluetooth on ArmSoM Sige1 result in tx timeout when using dma-names = "tx", "rx" as required by the dt-binding: Bluetooth: hci0: command 0x0c03 tx timeout Bluetooth: hci0: BCM: Reset failed (-110) Change the dmas order to fix UART DMA support on RK3528. With this fixed Bluetooth can be loaded using DMA on ArmSoM Sige1: Bluetooth: hci0: BCM: chip id 159 Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM4362A2 Bluetooth: hci0: BCM4362A2 (000.017.017) build 0000 Bluetooth: hci0: BCM4362A2 'brcm/BCM4362A2.hcd' Patch Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM43752A2 UART 37.4MHz Ampak AP6398 sLNA iLNA CL1 [Version: 1091.1173] Bluetooth: hci0: BCM4362A2 (000.017.017) build 1173 Fixes: ab6fcb58aedf ("arm64: dts: rockchip: Add UART DMA support for RK3528") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250709210831.3170458-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: Fix pinctrl node names for RK3528Jonas Karlman1-10/+10
[ Upstream commit f2792bf1c7a54ef23fb3a84286b66f427bfc4853 ] Following warnings can be observed with CHECK_DTBS=y for the RK3528: rk3528-pinctrl.dtsi:101.36-105.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:108.38-112.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:115.36-119.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:122.36-126.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:129.38-133.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:136.36-140.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:782.32-790.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:793.32-801.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-tx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:804.36-810.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_clk: Character '_' not recommended in node name rk3528-pinctrl.dtsi:813.36-823.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_bus: Character '_' not recommended in node name Rename the affected nodes to fix these warnings. Fixes: a31fad19ae39 ("arm64: dts: rockchip: Add pinctrl and gpio nodes for RK3528") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250621113859.2146400-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: freescale: imx8mp-toradex-smarc: fix lvds dsi mux gpioMax Krummenacher2-5/+2
[ Upstream commit 29d34c678cf82341cb0bedb3179d59c56856a80f ] The MUX which either outputs DSI or 2nd channel LVDS signals is part of the SoM. Move the pinmuxing of the GPIO used for controlling the MUX to the SoM dtsi file. Fixes: 97dc91c04558 ("arm64: dts: freescale: add Toradex SMARC iMX8MP") Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speedAdam Ford1-0/+2
[ Upstream commit e16ad6c79906bba5e2ac499492b6a5b29ab19d6c ] The reference manual for the i.MX8MN states the clock rate in MMC mode is 1/2 of the input clock, therefore to properly run at HS400 rates, the input clock must be 400MHz to operate at 200MHz. Currently the clock is set to 200MHz which is half the rate it should be, so the throughput is half of what it should be for HS400 operation. Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speedAdam Ford1-0/+2
[ Upstream commit f83f69097a302ed2a2775975ddcf12e6a5ac6ec3 ] The reference manual for the i.MX8MM states the clock rate in MMC mode is 1/2 of the input clock, therefore to properly run at HS400 rates, the input clock must be 400MHz to operate at 200MHz. Currently the clock is set to 200MHz which is half the rate it should be, so the throughput is half of what it should be for HS400 operation. Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: st: fix timer used for ticksPatrick Delaunay1-1/+1
[ Upstream commit 9ec406ac4b7de3e8040a503429d1a5d389bfdaf6 ] Remove always-on on generic ARM timer as the clock source provided by STGEN is deactivated in low power mode, STOP1 by example. Fixes: 5d30d03aaf78 ("arm64: dts: st: introduce stm32mp25 SoCs family") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20250515151238.1.I85271ddb811a7cf73532fec90de7281cb24ce260@changeid Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: fix PHY handling for ROCK 4DSebastian Reichel1-2/+4
[ Upstream commit cd803da7c033e376a66793a43ee98e136bc6cc25 ] Old revisions of the ROCK 4D board have a dedicated crystal to supply the RTL8211F PHY's 25MHz clock input. At least some newer revisions instead use REFCLKO25M_GMAC0_OUT. The DT already has this half-prepared, but there are some issues: 1. The DT relies on auto-selecting the right PHY driver, which requires that it works good enough to read the ID registers. This does not work without the clock, which is handled by the PHY driver. By updating the compatible to contain the RTL8211F IDs, so that the operating system can choose the right PHY driver without relying on a pre-powered PHY. 2. Despite the name REFCLKO25M_GMAC0_OUT could also provide a different frequency, so ensure it is explicitly set to 25 MHz as expected by the PHY. 3. While at it switch from deprecated "enable-gpio" to standard "enable-gpios". Fixes: a0fb7eca9c09 ("arm64: dts: rockchip: Add Radxa ROCK 4D device tree") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250704-rk3576-rock4d-phy-handling-fixes-v1-1-1d64130c4139@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am62p-verdin: fix PWM_3_DSI GPIO directionParth Pancholi1-1/+1
[ Upstream commit b1a8daa7cf2650637f6cca6aaf014bee89672120 ] PWM_3_DSI is used as the HDMI Hot-Plug Detect (HPD) GPIO for the Verdin DSI-to-HDMI adapter. After the commit 33bab9d84e52 ("arm64: dts: ti: k3-am62p: fix pinctrl settings"), the pin was incorrectly set as output without RXACTIVE, breaking HPD detection and display functionality. The issue was previously hidden and worked by chance before the mentioned pinctrl fix. Fix the pinmux configuration to correctly set PWM_3_DSI GPIO as an input. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20250703084534.1649594-1-parth105105@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: renesas: r8a779g3-sparrow-hawk-fan-pwm: Add missing install targetNiklas Söderlund1-0/+1
[ Upstream commit 7e5624e231eea73a6a2c2d0b837a085267590167 ] The target to consider the dtbo file for installation is missing, add it. Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support") Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/20250701112612.3957799-2-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am62p-verdin: add SD_1 CD pull-upFrancesco Dolcini1-1/+1
[ Upstream commit fefaa8d7f8012249729a987d3abce747ffab0ca7 ] Add internal pull-up to the SD_1 card detect signal, without this the CD signal is floating and spurious detects events can happen. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20250701081643.71406-1-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: imx8mp-venice-gw74xx: update name of M2SKT_WDIS2# gpioTim Harvey1-4/+4
[ Upstream commit 26a6a9cde64a890997708007d9de25809970eac9 ] The GW74xx D revision has added a M2SKT_WDIS2# GPIO which routes to the W_DISABLE2# pin of the M.2 socket. Update the gpio name for consistency. Fixes: 6a5d95b06d93 ("arm64: dts: imx8mp-venice-gw74xx: add M2SKT_GPIO10 gpio configuration") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: Enable eMMC HS200 mode on Radxa E20CJonas Karlman1-0/+1
[ Upstream commit 6e3071f4e03997ca0e4388ca61aa06df2802dcd1 ] eMMC HS200 mode (1.8V I/O) is supported by the MMC host controller on RK3528 and works with the optional on-board eMMC module on Radxa E20C. Be explicit about HS200 support in the device tree for Radxa E20C. Fixes: 3a01b5f14a8a ("arm64: dts: rockchip: Enable onboard eMMC on Radxa E20C") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250621165832.2226160-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single sizeMichael Walle1-1/+1
[ Upstream commit fdc8ad019ab9a2308b8cef54fbc366f482fb746f ] Pinmux registers ends at 0x000f42ac (including). Thus, the size argument of the pinctrl-single node has to be 0x2b0. Fix it. This will fix the following error: pinctrl-single f4000.pinctrl: mux offset out of range: 0x2ac (0x2ac) Fixes: 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs") Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20250618065239.1904953-1-mwalle@kernel.org Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am62p-verdin: Enable pull-ups on I2C_3_HDMIEmanuele Ghidoli1-2/+2
[ Upstream commit cb2d9c00770e2e6c51864704b5d98c9a0ddccaf9 ] Enable internal bias pull-ups on the SoC-side I2C_3_HDMI that do not have external pull resistors populated on the SoM. This ensures proper default line levels. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20250529102601.452859-1-ghidoliemanuele@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet portsWadim Egorov1-0/+2
[ Upstream commit 945e48a39c957924bc84d1a6c137da039e13855b ] For the ICSSG PHYs to operate correctly, a 25 MHz reference clock must be supplied on CLKOUT0. Previously, our bootloader configured this clock, which is why the PRU Ethernet ports appeared to work, but the change never made it into the device tree. Add clock properties to make EXT_REFCLK1.CLKOUT0 output a 25MHz clock. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Fixes: 87adfd1ab03a ("arm64: dts: ti: am642-phyboard-electra: Add PRU-ICSSG nodes") Link: https://lore.kernel.org/r/20250521053339.1751844-1-w.egorov@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>