u-boot.git/dts/upstream/src/arm64, branch v2025.10

arm64: dts: rockchip: force PMIC reset behavior to restart PMU on RK3588 Tiger

2025-08-30T15:28:20Z

The bootloader for RK3588 Tiger currently forces the PMIC reset behavior (stored in RST_FUN bitfield in register SYS_CFG3 of the PMIC) to 0b1X which is incorrect for our devices. It is required to restart the PMU as otherwise the companion microcontroller cannot detect the PMIC (and by extension the full product and main SoC) being rebooted which is an issue as that is used to reset a few things like the PWM beeper and watchdogs. Let's add the new rockchip,reset-mode property to make sure the PMIC reset behavior is the expected one. Signed-off-by: Quentin Schulz Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-5-ce05d041b45f@cherry.de Signed-off-by: Heiko Stuebner [ upstream commit: e82f642b9821384045915dc30e73df7de8424827 ] (cherry picked from commit d9c568906be166834f4f977bc7f704176bac5b8a) Reviewed-by: Kever Yang

arm64: dts: rockchip: force PMIC reset behavior to restart PMU on RK3588 Jaguar

2025-08-30T15:28:20Z

The bootloader for RK3588 Jaguar currently forces the PMIC reset behavior (stored in RST_FUN bitfield in register SYS_CFG3 of the PMIC) to 0b1X which is incorrect for our devices. It is required to restart the PMU as otherwise the companion microcontroller cannot detect the PMIC (and by extension the full product and main SoC) being rebooted which is an issue as that is used to reset a few things like the PWM beeper and watchdogs. Let's add the new rockchip,reset-mode property to make sure the PMIC reset behavior is the expected one. Signed-off-by: Quentin Schulz Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-4-ce05d041b45f@cherry.de Signed-off-by: Heiko Stuebner [ upstream commit: ee907113430aa02a8202c91bb574c385ecc28aa2 ] (cherry picked from commit 8bd14566b75f9409de703a0d2f9a0704b71a7ebe) Reviewed-by: Kever Yang

arm64: dts: rockchip: add header for RK8XX PMIC constants

2025-08-30T15:28:20Z

To make it easier to read the device tree, let's add constants for the rockchip,reset-mode property values that are currently only applicable to RK806 PMIC. Signed-off-by: Quentin Schulz [dt-maintainers did not consider this part of the binding, so we're keeping the header in the devicetree directory] Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-3-ce05d041b45f@cherry.de Signed-off-by: Heiko Stuebner [ upstream commit: 304be20e65ca08fc2e9cb58eb939a0054d8a8b81 ] (cherry picked from commit 0e417bfcbc385c127c7f5ea01df6289aed8325c2) Reviewed-by: Kever Yang

Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream

2025-07-30T15:53:54Z

[1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git Perform a few fixups in our dts* files to match upstream changes. Signed-off-by: Tom Rini

Merge patch series "rockchip: puma-rk3399: anticipate breakage with v6.16 DT"

2025-07-30T14:23:01Z

Quentin Schulz says: Due to updates to the Device Tree (migrating to onboard USB hub nodes instead of (badly) hacking things with a gpio regulator that doesn't actually work properly), we now need to enable the onboard USB hub driver in U-Boot. This anticipates upcoming breakage when 6.16 DT will be merged into U-Boot's dts/upstream. The series can be applied as is before v6.16 DT is merged or only the defconfig changes after 6.16 DT has been merged. The last two patches are simply to avoid probing devices that aren't actually routed on RK3399 Puma, which is nice to have but doesn't fix anything. Note that this depends on the following series: https://lore.kernel.org/u-boot/20250722-usb_onboard_hub_cypress_hx3-v4-0-91c3ee958c0e@thaumatec.com/ Link: https://lore.kernel.org/r/20250730-puma-usb-cypress-v1-0-b1c203c733f9@cherry.de

arm64: dts: rockchip: disable unrouted USB controllers and PHY on RK3399 Puma with Haikou

2025-07-30T14:23:00Z

The u2phy0_host port is the part of the USB PHY0 (namely the HOST0_DP/DM lanes) which routes directly to the USB2.0 HOST controller[1]. The other lanes of the PHY are routed to the USB3.0 OTG controller (dwc3), which we do use. The HOST0_DP/DM lanes aren't routed on RK3399 Puma so let's simply disable the USB2.0 controllers. USB3 OTG has been known to be unstable on RK3399 Puma Haikou for a while, one of the recurring issues being that only USB2 is detected and not USB3 in host mode. Reading the justification above and seeing that we are keeping u2phy0_host in the Haikou carrierboard DTS probably may have bothered you since it should be changed to u2phy0_otg. The issue is that if it's switched to that, USB OTG on Haikou is entirely broken. I have checked the routing in the Gerber file, the lanes are going to the expected ball pins (that is, NOT HOST0_DP/DM). u2phy0_host is for sure the wrong part of the PHY to use, but it's the only one that works at the moment for that board so keep it until we figure out what exactly is broken. No intended functional change. [1] https://rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf Chapter 2 USB2.0 PHY Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by: Quentin Schulz Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-5-4a76a474a010@thaumatec.com Signed-off-by: Heiko Stuebner [ upstream commit: febd8c6ab52c683b447fe22fc740918c86feae43 ] (cherry picked from commit 0a0ebebfdd4558512675e1aff34bddb770086cb0)

arm64: dts: rockchip: disable unrouted USB controllers and PHY on RK3399 Puma

2025-07-30T14:23:00Z

The u2phy1_host port is the part of the USB PHY1 (namely the HOST1_DP/DM lanes) which routes directly to the USB2.0 HOST controller[1]. The other lanes of the PHY are routed to the USB3.0 OTG controller (dwc3), which we do use. The HOST1_DP/DM lanes aren't routed on RK3399 Puma so let's simply disable the USB2.0 controllers and associated part in USB2.0 PHY. No intended functional change. [1] https://rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf Chapter 2 USB2.0 PHY Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by: Quentin Schulz Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-4-4a76a474a010@thaumatec.com Signed-off-by: Heiko Stuebner [ upstream commit: 3373af1d76bacd054b37f3e10266dd335ce425f8 ] (cherry picked from commit 97640da1f41d022484c1a4725bed943a5ae56073)

arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma

2025-07-30T14:23:00Z

Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable@vger.kernel.org # 6.6 Cc: stable@vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thaumatec.com Signed-off-by: Heiko Stuebner [ upstream commit: d7cc532df95f7f159e40595440e4e4b99481457b ] (cherry picked from commit 0fe42d171081426ab119ca5c0eb130e5f3a9a805)

Merge patch series "rockchip: ringneck-px30: anticipate breakage with v6.16-rc1 DT"

2025-07-30T14:21:00Z

Quentin Schulz says: v6.16-rc1 will bring an incompatible change to the Device Tree of PX30 Ringneck which will break Ethernet support. Unfortunately, the designware net driver's logic doesn't seem to allow having the old Device Tree (without MDIO bus and Ethernet PHY nodes) with DM_MDIO and DM_ETH_PHY enabled so there cannot be a smooth transition. Since this is going to bite me in a few months time, let's just break and fix it now in a couple of commits so I don't have to think about it later :) This can be cleanly applied on master or next, I have absolutely zero preference on the branch this should be merged in (my opinion is that it's too late in the 2024.07 cycle to bring this in :) ). Link: https://lore.kernel.org/r/20250611-ringneck-mdio-v1-0-529a40a0f966@cherry.de

arm64: dts: rockchip: move reset to dedicated eth-phy node on ringneck

2025-07-30T14:20:51Z

Using snps,reset-* properties to handle the ethernet-phy resets is deprecated and instead a real phy node should be used. Move the Ringneck phy-reset properties to such a node Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Tested-by: Quentin Schulz Link: https://lore.kernel.org/r/20250514150745.2437804-3-heiko@sntech.de Signed-off-by: Heiko Stuebner [ upstream commit: e463625af7f92c4a9f097f7fb87f6baaad6e762a ] (cherry picked from commit 76d0d8e00c9ac845ca8d6cbe191cf015ca3a8c16) Reviewed-by: Sumit Garg