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

doc: Update mentions of README.fdt-control

2025-09-27T07:20:22+00:00

Update documents 'README.fdt-control' reference to replacement 'control.rst':
  doc/arch/nios2.rst
  dts/Makefile

Also convert some adjacent pathname mentions to rST links where applicable

Fixes: 3e9fddfc4f14 "doc: Move devicetree control doc to rST"
Signed-off-by: E Shattow

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

2025-08-30T15:28:20+00:00

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:20+00:00

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:20+00:00

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

dt-bindings: mfd: rk806: Allow to customize PMIC reset mode

2025-08-30T15:28:20+00:00

The RK806 PMIC allows to configure its reset/restart behavior whenever
the PMIC is reset either programmatically or via some external pins
(e.g. PWRCTRL or RESETB).

The following modes exist:
 - 0; restart PMU,
 - 1; reset all power off reset registers and force state to switch to
   ACTIVE mode,
 - 2; same as mode 1 and also pull RESETB pin down for 5ms,

For example, some hardware may require a full restart (mode 0) in order
to function properly as regulators are shortly interrupted in this mode.

This is the case for RK3588 Jaguar and RK3588 Tiger which have a
companion microcontroller running on an independent power supply and
monitoring the PMIC power rail to know the state of the main system.
When it detects a restart, it resets its own IPs exposed to the main
system as if to simulate its own reset. Failing to perform this fake
reset of the microcontroller may break things (e.g. watchdog not
automatically disabled, buzzer still running until manually disabled,
leftover configuration from previous main system state, etc...).

Some other systems may be depending on the power rails to not be
interrupted even for a small amount of time[1].

This allows to specify how the PMIC should perform on the hardware level
and may differ between hardware designs, so a DT property seems
warranted. I unfortunately do not see how this could be made generic
enough to make it a non-vendor property.

[1] https://lore.kernel.org/linux-rockchip/2577051.irdbgypaU6@workhorse/

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Quentin Schulz 
Reviewed-by: "Rob Herring (Arm)" 
Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-1-ce05d041b45f@cherry.de
Signed-off-by: Lee Jones 

[ upstream commit: 404005d1083997daec7236620b9ba14bccdce449 ]

(cherry picked from commit 8ee72356e9844265334fd344bc05139d1f615c4d)
Reviewed-by: Kever Yang

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

2025-07-30T15:53:54+00:00

[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:01+00:00

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:00+00:00

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:00+00:00

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:00+00:00

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)