DTS: Fix the headphone detection on the orangepi 5 plus

[leggewie]

https://patchwork.kernel.org/project/linux-rockchip/patch/20250823-orangepi5-v1-1-ae77dd0e06d7@hotmail.com/ https://forum.armbian.com/topic/52118-hdmi-audio-and-analog-audio-do-not-work-on-opi5plus/#findComment-224923

There is an error in the DTS file for the Opi 5+. Question is if the same is true for the Opi 5 Pro: patch/kernel/archive/rockchip64-6.16/dt/rk3588s-orangepi-5-pro.dts

Testing: I have compile-tested this. The change has been run-time tested by the forum user "The Tall Man", but let's consider this PR a draft for now.

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

• patch/kernel/archive/rockchip64-6.16/dt/rk3588-orangepi-5-plus.dts is excluded by !patch/**

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[leggewie]

ping @alexl83 would you be so kind to test?

[EvilOlaf]

Since #8703 would you rebase on that? Is it even necessary to have a whole device tree replacing mainline or wouldn't a simple patch be sufficient?

[leggewie]

Since #8703 would you rebase on that? Is it even necessary to have a whole device tree replacing mainline or wouldn't a simple patch be sufficient?

I assume you are not talking about a git rebase, as there is no conflict with HEAD. I did that nonetheless since it's easy enough to do.

I do not have the device, so I cannot say if this change actually does what it hopes to do or if that is dependent on the version of the kernel used. I pinged the maintainer and a couple of people who I think might have access to the device but got no response.

Nothing further I can do here, really.

PS: Yes, a patch to an existing file might be better going forward. But if there is no run-time testing than the work to accomplish that would be in vain, so I'll wait for that to happen.

[paolosabatino]

PS: Yes, a patch to an existing file might be better going forward. But if there is no run-time testing than the work to accomplish that would be in vain, so I'll wait for that to happen.

Generally if there is already a DTS for the board in the mainline kernel, a patch is better because it won't hinder future changes to the DTS in the mainline kernel; otherwise, if the mainline kernel has no DTS yet, then a full DTS in armbian is fine.

About the rebase, I can do it later... it actually depends on which PR gets merged first: this or #8703 - I guess this PR is simpler and thus will get through first, then I will do the rebase.

[leggewie]

About the rebase, I can do it later... it actually depends on which PR gets merged first: this or #8703

#8703 was merged