kernel/linux.git/arch/arm64/boot, branch v6.18.44

arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers

2026-08-03T09:22:09+00:00

[ Upstream commit c17e220946675232d383620ed9cff6685735ec48 ] According to internal documentation, the corners specific for each rate from the DP link clock are: - LOWSVS_D1 -> 19.2 MHz - LOWSVS -> 270 MHz - SVS -> 540 MHz (594 MHz in case of DP3) - SVS_L1 -> 594 MHz - NOM -> 810 MHz - NOM_L1 -> 810 MHz - TURBO -> 810 MHz So fix all tables for each of the four controllers according to the documentation, but since DP0 through DP2 have the same entries in their tables, lets drop the DP1 and DP2 and have all of them share the DP0 table instead. However keep a separate table for the DP3 as it is different for the SVS, compared to the rest of the controllers. The 19.2 MHz @ LOWSVS_D1 isn't needed as it's not an actual working frequency and the controller will never select it. So remove it. Cc: stable@vger.kernel.org # v6.9+ Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes") Suggested-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260323-hamoa-fix-dp3-opp-table-v3-1-a823776bd1b0@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

arm64: dts: qcom: correct RBR opp entry

2026-08-03T09:22:09+00:00

[ Upstream commit a5c21b9bd5f531e50141b0484faabb707b92f1e2 ] DisplayPort Reduced Bit Rate uses link rate of 1.62 Gbps, the main link clock should be 162 MHz. Having the incorrect frequency (160 MHz) in the OPP table will result in selecting wrong link frequency. Correct the entry in the OPP table. Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-msm-fix-rbr-v1-1-b9eba986eaef@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: c17e22094667 ("arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234

2026-08-03T09:21:27+00:00

[ Upstream commit 0dfa1e960f86e032007882b032c5cc7d14ebe73e ] The Tegra234 SoC uses Cortex-A78AE cores, not Cortex-A78. Update the compatible string for all CPU nodes to match the actual hardware. Tegra234 hardware reports: # head /proc/cpuinfo | egrep 'implementer|part' CPU implementer : 0x41 CPU part : 0xd42 Which maps to (from arch/arm64/include/asm/cputype.h): #define ARM_CPU_IMP_ARM 0x41 #define ARM_CPU_PART_CORTEX_A78AE 0xD42 Fixes: a12cf5c339b08 ("arm64: tegra: Describe Tegra234 CPU hierarchy") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

arm64: tegra: Remove fallback compatible for GPCDMA

2026-08-03T09:21:27+00:00

[ Upstream commit ee7863e43228a3143398dc5bbb943c9a735a8fca ] Remove the fallback compatible string "nvidia,tegra186-gpcdma" for GPCDMA in Tegra264. Tegra186 compatible cannot work on Tegra264 because of the register offset changes and absence of the reset property. Fixes: 65ef237e4810 ("arm64: tegra: Add Tegra264 support") Signed-off-by: Akhil R Reviewed-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags

2026-07-24T14:16:52+00:00

commit b4f5c46163b3fe3ec7ed8a76dff8b7e80a776a1f upstream. IRQ_TYPE_xxx flags are not correct in the context of GPIO flags. These are simple defines so they could be used in DTS but they will not have the same meaning: IRQ_TYPE_EDGE_FALLING = 2 = GPIO_SINGLE_ENDED. Correct the Type-C int-gpios to use proper flags, assuming the author of the code wanted similar logical behavior: IRQ_TYPE_EDGE_FALLING => GPIO_ACTIVE_LOW Fixes: c4b4593ecb0b ("arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman

arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc

2026-07-24T14:16:52+00:00

commit d8fe8442366ffd8306575028bda92389d0dfb674 upstream. Add bootph-all property to vqmmc voltage regulator node and its corresponding pinmux node to make it available during all boot phases. This allows to run tuning early in SPL stages of boot. Fixes: 8f023012eb4a ("arm64: dts: ti: k3-am62a: Enable UHS mode support for SD cards") Cc: stable@vger.kernel.org Signed-off-by: Judith Mendez Link: https://patch.msgid.link/20260324140247.1200631-1-jm@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Greg Kroah-Hartman

arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck

2026-07-24T14:16:52+00:00

commit ae653cb854f36d1555681ce70ca3d80d0ec73516 upstream. When not passing the PHY ID with an ethernet-phy-idX.Y compatible property, the MDIO bus will attempt to auto-detect the PHY by reading its registers and then probing the appropriate driver. For this to work, the PHY needs to be in a working state. Unfortunately, the net subsystem doesn't control the PHY reset GPIO when attempting to auto-detect the PHY. This means the PHY needs to be in a working state when entering the Linux kernel. This historically has been the case for this device, but only because the bootloader was taking care of initializing the Ethernet controller even when not using it. We're attempting to support the removal of the network stack in the bootloader, which means the Linux kernel will be entered with the PHY still in reset and now Ethernet doesn't work anymore. The devices in the field only ever had a TI DP83825, so let's simply bypass the auto-detection mechanism entirely by passing the appropriate PHY IDs via the compatible. Note that this is only an issue since commit e463625af7f9 ("arm64: dts: rockchip: move reset to dedicated eth-phy node on ringneck") as before that commit the reset was done by the MAC controller before starting the MDIO auto-detection mechanism, via the snps,reset-* properties. Cc: stable@vger.kernel.org Fixes: e463625af7f9 ("arm64: dts: rockchip: move reset to dedicated eth-phy node on ringneck") Signed-off-by: Quentin Schulz Link: https://patch.msgid.link/20260421-px30-eth-phy-v2-2-68c375b120fd@cherry.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman

arm64: dts: qcom: sdm630: describe adsp_mem region properly

2026-07-24T14:16:52+00:00

commit ce414263e9ebe5080381a50cbdf9065c29816202 upstream. Downstream [1] this region is marked as shared, reusable and dynamic so describe it that way. [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448 Fixes: b190fb010664 ("arm64: dts: qcom: sdm630: Add sdm630 dts file") Cc: stable@vger.kernel.org Reviewed-by: Ekansh Gupta Reviewed-by: Dmitry Baryshkov Signed-off-by: Nickolay Goppen Link: https://lore.kernel.org/r/20260429-qcom-sdm660-cdsp-adsp-fastrpc-dts-fix-v5-4-16bc82e622ad@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

arm64: dts: s32g3: Fix SWT8 watchdog address

2026-07-24T14:16:52+00:00

commit 65210e81f7837a871a17237d15e4b1191d5e8771 upstream. Add missing hex annotation to fix the SWT8 watchdog address in 'reg' property, as reported by dtc W=1: s32g3.dtsi:863.27-869.5: Warning (simple_bus_reg): /soc@0/watchdog@40500000: simple-bus unit address format error, expected "269fb20" Lack of hex '0x' meant address would be interpreted as decimal thus completely different value used as this device MMIO. If device was enabled this could lead to corruption of other device address space and broken boot. Cc: stable@vger.kernel.org Fixes: 6db84f042745 ("arm64: dts: s32g3: Add the Software Timer Watchdog (SWT) nodes") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Lezcano Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman

arm64: dts: allwinner: a523: Add missing GPIO interrupt

2026-07-24T14:16:08+00:00

[ Upstream commit 6b81aa0c8a4f038712fa549e4d44d8279eeb0440 ] Even though the Allwinner A523 SoC implements 10 GPIO banks, it has actually registers for 11 IRQ banks, and even an interrupt assigned to the first, non-implemented IRQ bank. Add that first interrupt to the list of GPIO interrupts, to correct the association between IRQs and GPIO banks. This fixes GPIO IRQ operation on boards with A523 SoCs, as seen by broken SD card detect functionality, for instance. Signed-off-by: Andre Przywara Fixes: 35ac96f79664 ("arm64: dts: allwinner: Add Allwinner A523 .dtsi file") Reviewed-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260327113006.3135663-4-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin