Re: [PATCH 2/2] arm64: dts: rockchip: Add Orange Pi 5 Pro board support

[Jimmy Hon]

On Mon, Mar 2, 2026 at 5:27 AM Heiko Stuebner <heiko@xxxxxxxxx> wrote:
>
> Hi Dennis,
>
> Am Samstag, 28. Februar 2026, 21:54:17 Mitteleuropäische Normalzeit schrieb dennis@xxxxxxxx:
> > From: Dennis Gilmore <dennis@xxxxxxxx>
> >
> > Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S). The Pro
> > differs from the base Orange Pi 5 in the following ways:
> >
> > - No SPI NOR flash; eMMC module slot instead, you can optionally solder
> >   a SPI NOR fin place and turn off the eMMC
> > - PCIe-attached NIC (pcie2x1l1) replaces the GMAC1 ethernet
> > - PCIe NVMe slot (pcie2x1l2)
> > - AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
> > - BCM4345C5 Bluetooth via uart9 with full RTS/CTS
> > - Two-colour (blue/green) GPIO LED using modern color/function binding
> > - audio is wired up differently
> >
> > Vendors description and links to schematics available:
> > http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
> >
> > Signed-off-by: Dennis Gilmore <dennis@xxxxxxxx>
> > ---
> >  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
> >  .../dts/rockchip/rk3588s-orangepi-5-pro.dts   | 376 ++++++++++++++++++
> >  2 files changed, 377 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> > index 4d384f153c13..c99dca2ae9e7 100644
> > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > @@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
> > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> > new file mode 100644
> > index 000000000000..d656328c906d
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> > @@ -0,0 +1,376 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +
> > +/dts-v1/;
> > +
> > +#include "rk3588s-orangepi-5.dtsi"
> > +
> > +/ {
> > +     model = "Xunlong Orange Pi 5 Pro";
> > +     compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
> > +
> > +     aliases {
> > +             /delete-property/ ethernet0;
> > +             mmc0 = &sdhci;
> > +             mmc1 = &sdmmc;
> > +             mmc2 = &sdio;
> > +     };
> > +
> > +     /* Pro uses gpio-leds instead; pwm0 LED is not wired up */
> > +     /delete-node/ pwm-leds;
> > +
> > +     /*
> > +      * Pro uses i2s2 (i2s2m1 mux) for audio, not i2s1. Recreate the sound
> > +      * card node pointing at i2s2_2ch instead.
> > +      */
> > +     /delete-node/ analog-sound;
>
> I think it would make more sense to move the relevant not-shared part
> out of the dtsi instead. Yes the duplication in orangepi-5 and orangepi-5b
> should be fine.
>
> Having a devicetree with so many /delete-node/ and /delete-property/
> elements sprinkled throughout the file, will definitly cause readability
> (and handling issues) in the future.
>
> Additionally this makes all the comments in the file explaining individual
> difference unnecessary.
>
>
> Thanks
> Heiko
>
Hi Dennis,

You could follow the pattern that was used for the full RK3588 Orange
Pi 5 boards.
The Orange Pi 5 Max and Ultra are very similar, so they both share a
DTSI. However, the parts that are also common with the Orange Pi 5
Plus are put into a common DTSI that is used by all 3 boards.

So for these RK3588s Orange Pi 5 boards, you could refactor the
existing DTSI to separate the parts that are only used by the older
DDR4 Orange Pi 5 and 5B, from the parts that are common to all 3
boards.

To verify the existing Orange Pi 5 and 5B boards DTBs are not damaged,
you should be able to convert the DTBs to DTSs before refactoring as a
baseline, and then after the refactoring, convert the DTBs to DTSs and
compare with the baseline.

As an example of the delete-node/delete-property leading to problems
in the future is when DisplayPort AltMode is added to the 5 and 5B.
The new properties will be inherited into the 5 Pro device tree, when
they are not wanted.

Jimmy