dts: orangepi-4-lts: fix mispelled disable properites

[EvilOlaf]

Description

Backports a fix for Orangepi 4 LTS where status values were mispelled ('disable' instead of 'disabled').

I'm not sure if these nodes were actually active due to this typo (it seems like this kind of issue is silently ignored by dtc).

How Has This Been Tested?

• build
• boot - nope, no hw

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

Summary by CodeRabbit

• Bug Fixes
  • Corrected hardware component status configuration on OrangePi 4 LTS boards, affecting audio, backlight, SPI, and display interfaces.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The change corrects device-tree status properties in a Rockchip RK3399 Orange Pi 4 LTS board definition file. Multiple device nodes have their status property value updated from the invalid "disable" string to the correct "disabled" string.

Changes

Cohort / File(s)	Summary
Device-tree status corrections patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts	Status property value corrections from "disable" to "disabled" across multiple device nodes (spdif-sound, spdif-out, pwm_bl, spi1, spdif, hdmi_in_vopl, dp_in_vopb, dp_in_vopl, and i2c7 spdif); ensures proper device-tree syntax compliance

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Suggested reviewers

• igorpecovnik
• joekhoobyar
• brentr
• prahal
• krachlatte
• lanefu
• paolosabatino
• pyavitz
• rpardini
• catalinii

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: fixing misspelled 'disable' properties to 'disabled' in the device tree file.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

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

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 60e869c and 6f9dfcc.

📒 Files selected for processing (1)

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

🧰 Additional context used

🧠 Learnings (9)

📓 Common learnings

Learnt from: EvilOlaf
Repo: armbian/build PR: 9067
File: patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts:869-875
Timestamp: 2025-12-23T04:44:25.212Z
Learning: When reviewing device tree changes, validate node properties against the official kernel device tree binding documentation (*.yaml files) rather than relying solely on historical patterns in existing DTS files. Copy-paste errors can persist across versions, and bindings define the authoritative set of valid properties for each device node type.

Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.

Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.

Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.

Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.

Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.

Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.

📚 Learning: 2025-11-08T06:39:24.527Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

📚 Learning: 2025-12-17T05:09:02.306Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

📚 Learning: 2025-11-20T18:20:11.985Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

📚 Learning: 2025-12-23T04:44:25.212Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 9067
File: patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts:869-875
Timestamp: 2025-12-23T04:44:25.212Z
Learning: During code reviews of device tree changes (any .dts file), verify node properties against the official kernel device tree binding documentation (*.yaml) rather than relying solely on patterns observed in existing DTS files. This helps catch copy-paste or drift errors and ensures properties align with authoritative bindings for each device node type.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

📚 Learning: 2025-12-19T13:56:45.124Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

📚 Learning: 2025-09-14T06:32:29.806Z

Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

📚 Learning: 2025-12-17T15:46:22.709Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 9096
File: patch/kernel/archive/sunxi-6.18/patches.armbian/arm64-dts-sun50i-h616-add-overlays.patch:4-5
Timestamp: 2025-12-17T15:46:22.709Z
Learning: In Armbian kernel patches, when patches are renamed or reorganized, the old Subject line may be intentionally preserved in the patch header (as a second Subject line) for archival/historical purposes to document the previous patch name. This is an Armbian-specific practice for tracking patch evolution and should not be flagged as an error when the maintainer has intentionally included it for documentation.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

📚 Learning: 2025-12-13T11:00:33.143Z

Learnt from: pyavitz
Repo: armbian/build PR: 9058
File: patch/kernel/archive/spacemit-6.6/dt/lcd_tc358762xbg_dpi_800x480.dtsi:3-61
Timestamp: 2025-12-13T11:00:33.143Z
Learning: On the SpacemiT MusePi Pro board with spacemit-6.6 kernel, LCD/DSI support is disabled in k1-musepi-pro.dts because enabling it causes the unit to lock up during boot. The lcd_tc358762xbg_dpi_800x480.dtsi file exists but DSI remains disabled at the controller level.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

🔇 Additional comments (2)

patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts (2)

213-213: Correct device tree status property typo.

The status property corrections from "disable" to "disabled" are correct and necessary. Per the device tree specification, "disabled" is the valid value to mark a device as non-operational, while "disable" is not a recognized status value and could lead to undefined behavior or silent misinterpretation by the device tree compiler.

Also applies to: 225-225, 231-231, 871-871

---

458-458: Correct device tree status property typo for display routing and SPI.

The status property corrections for SPI1, HDMI input from VOPL, and DisplayPort input from VOPB are correct. These nodes use the proper "disabled" value, ensuring the device tree compiler correctly interprets the disabled state for these hardware components.

Also applies to: 1261-1261, 1265-1265

---

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.}