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

[SuperKali]

@leggewie Since the branch edge is on kernel 6.18, does it make more sense to keep this PR open? Have the changes been made on the current kernel edge?
If the problem is also present on the current edge kernel, it would be advisable to update this PR.

Thank you.