u-boot.git/dts, branch v2025.10-rc2

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)

dt-bindings: usb: cypress,hx3: Add support for all variants

2025-07-30T14:23:00Z

The Cypress HX3 hubs use different default PID value depending on the variant. Update compatibles list. Becasuse all hub variants use the same driver data, allow the dt node to have two compatibles: leftmost which matches the HW exactly, and the second one as fallback. Fixes: 1eca51f58a10 ("dt-bindings: usb: Add binding for Cypress HX3 USB 3.0 family") Cc: stable@vger.kernel.org # 6.6 Cc: stable@vger.kernel.org # Backport of the patch ("dt-bindings: usb: usb-device: relax compatible pattern to a contains") from list: https://lore.kernel.org/linux-usb/20250418-dt-binding-usb-device-compatibles-v2-1-b3029f14e800@cherry.de/ 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 Reviewed-by: "Rob Herring (Arm)" Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-2-4a76a474a010@thaumatec.com [taken with Greg's blessing] Signed-off-by: Heiko Stuebner [ upstream commit: 1ad4b5a7de16806afc1aeaf012337e62af04e001 ] (cherry picked from commit 53aacaed0ad140b017c803d9777473c6c62f5352)

dt-bindings: usb: usb-device: relax compatible pattern to a contains

2025-07-30T14:23:00Z

The dt-core typically allows multiple compatibles[1] but usb-device currently forces a single compatible. This is an issue when multiple devices with slightly different productID all behave the same. This would require the driver to keep updating its compatible matching table to include this new productID instead of doing what is usually done: have two compatibles, the leftmost which matches exactly the HW device definition, and the rightmost one as a fallback which is assumed to be 100% compatible with the device at hand. If this assumption turns out to be wrong, it is easy to work around this without having to modify the device tree by handling the leftmost compatible in the driver. [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/dt-core.yaml#L21-L25 Signed-off-by: Quentin Schulz Reviewed-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/20250418-dt-binding-usb-device-compatibles-v2-1-b3029f14e800@cherry.de Signed-off-by: Greg Kroah-Hartman [ upstream commit: 495df45f38c8ba3d74c3180a0a13a0ecbfa717d1 ] (cherry picked from commit 932da7a8df7b6b43453d640b383d0076d5a7d9a5)

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

arm64: dts: rockchip: add basic mdio node to px30

2025-07-30T14:20:51Z

Using snps,reset-* properties for handling the phy-reset is deprecated and instead a real phy node should be defined that then contains the reset-gpios handling. To facilitate this, add the core mdio node under the px30's gmac, similar to how the other Rockchip socs already do this. Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Link: https://lore.kernel.org/r/20250514150745.2437804-2-heiko@sntech.de Signed-off-by: Heiko Stuebner [ upstream commit: ede4837a504ca7e5811217060aa8300b8d0cf7f2 ] (cherry picked from commit cb54a264ecdb9e95b1529e4542e157cb9acded30) Reviewed-by: Sumit Garg