kernel/arch/arm64/boot, branch linux-6.19.y

arm64: dts: rockchip: Fix rk3588 PCIe range mappings

2026-03-04T12:21:23Z

[ Upstream commit 46c56b737161060dfa468f25ae699749047902a2 ] The pcie bus address should be mapped 1:1 to the cpu side MMIO address, so that there is no same address allocated from normal system memory. Otherwise it's broken if the same address assigned to the EP for DMA purpose.Fix it to sync with the vendor BSP. Fixes: 0acf4fa7f187 ("arm64: dts: rockchip: add PCIe3 support for rk3588") Fixes: 8d81b77f4c49 ("arm64: dts: rockchip: add rk3588 PCIe2 support") Cc: stable@vger.kernel.org Cc: Sebastian Reichel Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1767600929-195341-2-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

arm64: dts: rockchip: Fix rk356x PCIe range mappings

2026-03-04T12:21:23Z

[ Upstream commit f63ea193a404481f080ca2958f73e9f364682db9 ] The pcie bus address should be mapped 1:1 to the cpu side MMIO address, so that there is no same address allocated from normal system memory. Otherwise it's broken if the same address assigned to the EP for DMA purpose.Fix it to sync with the vendor BSP. Fixes: 568a67e742df ("arm64: dts: rockchip: Fix rk356x PCIe register and range mappings") Fixes: 66b51ea7d70f ("arm64: dts: rockchip: Add rk3568 PCIe2x1 controller") Cc: stable@vger.kernel.org Cc: Andrew Powers-Holmes Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1767600929-195341-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576

2026-03-04T12:21:23Z

[ Upstream commit 79a3286e61829fc43abdd6e3beb31b24930c7af6 ] Rockchip RK3576 UFS controller uses a dedicated pin to reset the connected UFS device, which can operate either in a hardware controlled mode or as a GPIO pin. Power-on default is GPIO mode, but the boot ROM reconfigures it to a hardware controlled mode if it uses UFS to load the next boot stage. Given that existing bindings (and rk3576.dtsi) expect a GPIO-controlled device reset, request the required pin config explicitly. The pin is requested with pull-down enabled, which is in line with the SoC power-on default and helps ensure that the attached UFS chip stays in reset until the driver takes over the control of the respective GPIO line. This doesn't appear to affect Linux, but it does affect U-boot: Before: => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ... > => ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2 => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ After: => md.l 0x2604b398 2604b398: 00000011 00000000 00000000 00000000 ................ < ... snip ...> => ufs init ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=[3, 3], lane[2, 2], pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate = 2 => md.l 0x2604b398 2604b398: 00000010 00000000 00000000 00000000 ................ (0x2604b398 is the respective pin mux register, with its BIT0 driving the mode of UFS_RST: unset = GPIO, set = hardware controlled UFS_RST) This helps ensure that GPIO-driven device reset actually fires when the system requests it, not when whatever black box magic inside the UFSHC decides to reset the flash chip. Cc: stable@vger.kernel.org Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC") Reported-by: Quentin Schulz Reviewed-by: Quentin Schulz Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260121-ufs-rst-v3-1-35839bcb4ca7@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

arm64: dts: rockchip: Do not enable hdmi_sound node on Pinebook Pro

2026-03-04T12:21:17Z

[ Upstream commit b18247f9dab735c9c2d63823d28edc9011e7a1ad ] Remove the redundant enabling of the hdmi_sound node in the Pinebook Pro board dts file, because the HDMI output is unused on this device. [1][2] This change also eliminates the following kernel log warning, which is caused by the unenabled dependent node of hdmi_sound that ultimately results in the node's probe failure: platform hdmi-sound: deferred probe pending: asoc-simple-card: parse error [1] https://files.pine64.org/doc/PinebookPro/pinebookpro_v2.1_mainboard_schematic.pdf [2] https://files.pine64.org/doc/PinebookPro/pinebookpro_schematic_v21a_20220419.pdf Cc: stable@vger.kernel.org Fixes: 5a65505a69884 ("arm64: dts: rockchip: Add initial support for Pinebook Pro") Signed-off-by: Jun Yan Reviewed-by: Peter Robinson Reviewed-by: Dragan Simic Link: https://patch.msgid.link/20260116151253.9223-1-jerrysteve1101@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

arm64: dts: rockchip: Fix SD card support for RK3576 Nanopi R76s

2026-03-04T12:21:15Z

[ Upstream commit a9c1acebfe0484343a443d082e039ca77186ed22 ] When runtime suspend is enabled, the associated power domain is powered off, which resets the registers, including the power control bit. As a result, the card loses power during runtime suspend. The card should still be able to process I/O with the help of mmc_blk_mq_rw_recovery(), which is suboptimal. To address this issue, we must use vmmc-supply with a GPIO based method to maintain power to the card and store valid tuning phases. Also, add cd-gpios method to make hot-plug work correctly during idle periods. Fixes: 7fee88882704 ("arm64: dts: rockchip: Add devicetree for the FriendlyElec NanoPi R76S") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Tested-by: Marco Schirrmeister Link: https://patch.msgid.link/1768524932-163929-6-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

arm64: dts: rockchip: Fix SD card support for RK3576 EVB1

2026-03-04T12:21:15Z

[ Upstream commit 7226664bf952c4cfddccd74b154a7d994608d153 ] When runtime suspend is enabled, the associated power domain is powered off, which resets the registers, including the power control bit. As a result, the card loses power during runtime suspend. The card should still be able to process I/O with the help of mmc_blk_mq_rw_recovery(), which is suboptimal. To address this issue, we must use vmmc-supply with a GPIO based method to maintain power to the card. Also, add cd-gpios method to make hot-plug work correctly during idle periods. Fixes: f135a1a07352 ("arm64: dts: rockchip: Add rk3576 evb1 board") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1768524932-163929-5-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

arm64: dts: ti: k3-am69-aquila-clover: Change main_spi2 CS0 to GPIO mode

2026-03-04T12:21:14Z

[ Upstream commit 319fff9c7d620af83d8ab67050a54f63f16ae4e8 ] Change CS0 from hardware chip select to GPIO-based chip select to align with the base aquila device tree configuration. Fixes: 9f748a6177e1 ("arm64: dts: ti: am69-aquila: Add Clover") Cc: stable@vger.kernel.org Signed-off-by: Vitor Soares Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260112175350.79270-3-ivitro@gmail.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin

arm64: dts: ti: k3-am69-aquila: Change main_spi0/2 CS to GPIO mode

2026-03-04T12:21:14Z

[ Upstream commit 78a123f45a7e9ac2a59f0eff8a37d31773e7a021 ] Hardware chip select does not work correctly on main_spi0 and main_spi2 controllers. Testing shows main_spi2 loses CS state during runtime PM suspend, while main_spi0 cannot drive CS HIGH when bus is idle. Use GPIO-based chip select for both controllers. Fixes: 39ac6623b1d8 ("arm64: dts: ti: Add Aquila AM69 Support") Cc: stable@vger.kernel.org Signed-off-by: Vitor Soares Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260112175350.79270-2-ivitro@gmail.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin

arm64: dts: apple: t8112-j473: Keep the HDMI port powered on

2026-03-04T12:21:08Z

[ Upstream commit 3e4e729325131fe6f7473a0673f7d8cdde53f5a0 ] Add the display controller and DPTX phy power-domains to the framebuffer node to keep the framebuffer and display out working after device probing finished. The OS has more control about the display pipeline used for the HDMI output on M2 based devices. The HDMI output is driven by an integrated DisplayPort to HDMI converter (Parade PS190). The DPTX phy is now controlled by the OS and no longer by firmware running on the display co-processor. This allows using the second display controller on the second USB type-c port or tunneling 2 DisplayPort connections over USB4/Thunderbolt. The m1n1 bootloader uses the second display controller to drive the HDMI output. Adjust for this difference compared to the notebooks as well. Fixes: 2d5ce3fbef32 ("arm64: dts: apple: t8112: Initial t8112 (M2) device trees") Cc: stable@vger.kernel.org Signed-off-by: Janne Grunau Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-1-cfdce629c0a8@jannau.net Signed-off-by: Sven Peter Signed-off-by: Sasha Levin

arm64: dts: qcom: sm8750: Fix BAM DMA probing

2026-03-04T12:21:06Z

[ Upstream commit 1c6192ec9c4ab8bdb7b2cf8763b7ef7e38671ffe ] Bindings always required "qcom,num-ees" and "num-channels" properties, as reported by dtbs_check: sm8750-mtp.dtb: dma-controller@1dc4000 (qcom,bam-v1.7.4): 'anyOf' conditional failed, one must be fixed: 'qcom,powered-remotely' is a required property 'num-channels' is a required property 'qcom,num-ees' is a required property 'clocks' is a required property 'clock-names' is a required property However since commit 5068b5254812 ("dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees") missing properties are actually fatal and BAM does not probe: bam-dma-engine 1dc4000.dma-controller: num-channels unspecified in dt bam-dma-engine 1dc4000.dma-controller: probe with driver bam-dma-engine failed with error -22 Fixes: eeb0f3e4ea67 ("arm64: dts: qcom: sm8750: Add QCrypto nodes") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251229115734.205744-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin