LED Color Naming Mismatch on OneCloudPro (S912)

[wuai1024]

Device Information | 设备信息

• SOC: Amlogic S912
• Model: Octopus Planet (OneCloudPro V1.2)

Armbian Version | 系统版本

• Kernel Version: 6.12.82-ophub
• Release: Armbian 26.2.1 noble

Describe the bug | 问题描述

All issues will only remain open for one week to prioritize resolving them.
After that period, they will be closed but can still continue to be discussed in the thread.

On the OneCloudPro (Octopus Planet) device, the LED sysfs filenames do not match the physical LED colors:

sysfs File	Expected	Actual Physical Color
/sys/class/leds/green/brightness	🟢 Green	🔴 Red
/sys/class/leds/red/brightness	🔴 Red	🟢 Green
/sys/class/leds/blue/brightness	🔵 Blue	🔵 Blue ✅

Steps to Reproduce | 复现步骤

# Expected: green LED turns on
$ echo 1 > /sys/class/leds/green/brightness
# Actual: RED physical LED turns on

# Expected: red LED turns on
$ echo 1 > /sys/class/leds/red/brightness
# Actual: GREEN physical LED turns on

Verification | 验证

Current brightness state:

$ cat /sys/class/leds/green/brightness  # Currently: 0
$ cat /sys/class/leds/red/brightness    # Currently: 1
$ cat /sys/class/leds/blue/brightness   # Currently: 0

Physical observation: 🟢 GREEN LED is on (matching red/brightness=1).

Device tree labels are correct (green/red/blue), so the swap happens at the GPIO/pin assignment level in the DTB.

Analysis | 分析

From /proc/device-tree/leds/:

• green_led label → physical red LED ❌
• red_led label → physical green LED ❌
• blue_led label → physical blue LED ✅

The /etc/armbian-leds.conf shows the correct state snapshot but uses the swapped naming convention.

Expected Behavior | 期望行为

The sysfs LED names should match their physical colors:

• /sys/class/leds/red/brightness → controls the red physical LED
• /sys/class/leds/green/brightness → controls the green physical LED
• /sys/class/leds/blue/brightness → controls the blue physical LED

Question | 问题

Is this a known issue for the OneCloudPro / Octopus Planet board? Is there a way to fix this via DTB overlay, or should this be reported to the board manufacturer?

Additional Context | 补充信息

• All three LEDs are fully software-controllable once the naming mapping is known
• The green_led also has trigger=usb-host, but the brightness control works independently
• This appears to be a board-specific GPIO/LED pin assignment error in the DTB

[ophub]

ophub/linux-6.12.y@4c7e2a8

Thanks for the feedback, it has been corrected.

https://github.com/ophub/kernel/actions/runs/24665219505

The kernel is currently being compiled and will take about 10 minutes. Once completed, you can proceed with the update. When prompted whether to force the update, select y to continue.

armbian-update -k 6.12 -u stable

[wuai1024]

armbian-update -k 6.12 -u stable

root@armbian:~# armbian-update -k 6.12 -u stable
[ STEPS ] Welcome to the kernel update tool.
[ STEPS ] Start checking dependencies...
[ INFO ] Dependency check completed.

[ STEPS ] Start initializing parameters...
[ INFO ] Armbian platform: [ amlogic ]
[ INFO ] Kernel download repository: [ ophub/kernel ]
[ INFO ] Kernel tags: [ stable ]
[ INFO ] Specify kernel: [ 6.12 ]
[ INFO ] Backup kernel: [ yes ]
[ INFO ] Armbian is running on: [ /dev/mmcblk2 ]

[ STEPS ] Start querying kernel version...
[ INFO ] You can access [ github.com ] normally.
[ INFO ] Query the latest kernel version of the [ 6.12 ] series within [ kernel_stable ]...
[ INFO ] Current version: [ 6.12.82 ], Latest version: [ 6.12.82 ].
[ FINISH ] The latest version is already installed, no update is needed.

In the case where it is already the latest version, how to update?

[ophub]

armbian-sync
armbian-update

[wuai1024]

Completed. Thank you.