[PATCH 0/2] arm64: dts: meson-gxbb-odroidc2: eFuse MAC address and LED properties

All of lore.kernel.org
 help / color / mirror / Atom feed

* [PATCH 0/2] arm64: dts: meson-gxbb-odroidc2: eFuse MAC address and LED properties
@ 2026-10-11 17:17 ` Fil Dunsky via B4 Relay
  0 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky via B4 Relay @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

Two small device-tree updates for the Hardkernel ODROID-C2, found while
adding OpenWrt support for the board.

Patch 1 wires the eth_mac eFuse nvmem cell (already described in
meson-gx.dtsi, but so far unused) to the Ethernet controller, so the
kernel reads the factory MAC address itself instead of relying on the
bootloader or a random fallback.

Patch 2 converts the blue status LED to the standard color/function
properties.

Both verified on ODROID-C2 hardware and rechecked against this tree
with CHECK_DTBS=y W=1.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
Fil Dunsky (2):
      arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
      arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
---
base-commit: a5ebb76233b79db01e82e061173cb73c6d2b5c6b
change-id: 20261011-odroidc2-dts-53a0b62433c1

Best regards,
--  
Fil Dunsky <filipp.dunsky@gmail.com>

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH 0/2] arm64: dts: meson-gxbb-odroidc2: eFuse MAC address and LED properties
@ 2026-10-11 17:17 ` Fil Dunsky via B4 Relay
  0 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

Two small device-tree updates for the Hardkernel ODROID-C2, found while
adding OpenWrt support for the board.

Patch 1 wires the eth_mac eFuse nvmem cell (already described in
meson-gx.dtsi, but so far unused) to the Ethernet controller, so the
kernel reads the factory MAC address itself instead of relying on the
bootloader or a random fallback.

Patch 2 converts the blue status LED to the standard color/function
properties.

Both verified on ODROID-C2 hardware and rechecked against this tree
with CHECK_DTBS=y W=1.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
Fil Dunsky (2):
      arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
      arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
---
base-commit: a5ebb76233b79db01e82e061173cb73c6d2b5c6b
change-id: 20261011-odroidc2-dts-53a0b62433c1

Best regards,
--  
Fil Dunsky <filipp.dunsky@gmail.com>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH 0/2] arm64: dts: meson-gxbb-odroidc2: eFuse MAC address and LED properties
@ 2026-10-11 17:17 ` Fil Dunsky via B4 Relay
  0 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky via B4 Relay @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

Two small device-tree updates for the Hardkernel ODROID-C2, found while
adding OpenWrt support for the board.

Patch 1 wires the eth_mac eFuse nvmem cell (already described in
meson-gx.dtsi, but so far unused) to the Ethernet controller, so the
kernel reads the factory MAC address itself instead of relying on the
bootloader or a random fallback.

Patch 2 converts the blue status LED to the standard color/function
properties.

Both verified on ODROID-C2 hardware and rechecked against this tree
with CHECK_DTBS=y W=1.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
Fil Dunsky (2):
      arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
      arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
---
base-commit: a5ebb76233b79db01e82e061173cb73c6d2b5c6b
change-id: 20261011-odroidc2-dts-53a0b62433c1

Best regards,
--  
Fil Dunsky <filipp.dunsky@gmail.com>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
  2026-10-11 17:17 ` Fil Dunsky via B4 Relay
  (?)
@ 2026-10-11 17:17   ` Fil Dunsky via B4 Relay
  -1 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky via B4 Relay @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

From: Fil Dunsky <filipp.dunsky@gmail.com>

The vendor programs a unique factory MAC address into the SoC eFuse at
offset 0x34, which is exactly the eth_mac nvmem cell that meson-gx.dtsi
already describes.  Reference the cell from the Ethernet controller so
the kernel picks up the factory address itself instead of depending on
the bootloader to populate local-mac-address, or falling back to a
random one when it does not.

Verified on an ODROID-C2 booted with a mainline U-Boot that does not
set ethaddr: the interface comes up with the factory MAC address.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 5943bc810..639b97ad5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -230,6 +230,9 @@ &ethmac {
 	phy-handle = <&eth_phy0>;
 	phy-mode = "rgmii";
 
+	nvmem-cells = <&eth_mac>;
+	nvmem-cell-names = "mac-address";
+
 	amlogic,tx-delay-ns = <2>;
 
 	mdio {

-- 
2.53.0



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
@ 2026-10-11 17:17   ` Fil Dunsky via B4 Relay
  0 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

The vendor programs a unique factory MAC address into the SoC eFuse at
offset 0x34, which is exactly the eth_mac nvmem cell that meson-gx.dtsi
already describes.  Reference the cell from the Ethernet controller so
the kernel picks up the factory address itself instead of depending on
the bootloader to populate local-mac-address, or falling back to a
random one when it does not.

Verified on an ODROID-C2 booted with a mainline U-Boot that does not
set ethaddr: the interface comes up with the factory MAC address.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 5943bc810..639b97ad5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -230,6 +230,9 @@ &ethmac {
 	phy-handle = <&eth_phy0>;
 	phy-mode = "rgmii";

+	nvmem-cells = <&eth_mac>;
+	nvmem-cell-names = "mac-address";
+
 	amlogic,tx-delay-ns = <2>;

 	mdio {

-- 
2.53.0

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
@ 2026-10-11 17:17   ` Fil Dunsky via B4 Relay
  0 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky via B4 Relay @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

From: Fil Dunsky <filipp.dunsky@gmail.com>

The vendor programs a unique factory MAC address into the SoC eFuse at
offset 0x34, which is exactly the eth_mac nvmem cell that meson-gx.dtsi
already describes.  Reference the cell from the Ethernet controller so
the kernel picks up the factory address itself instead of depending on
the bootloader to populate local-mac-address, or falling back to a
random one when it does not.

Verified on an ODROID-C2 booted with a mainline U-Boot that does not
set ethaddr: the interface comes up with the factory MAC address.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 5943bc810..639b97ad5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -230,6 +230,9 @@ &ethmac {
 	phy-handle = <&eth_phy0>;
 	phy-mode = "rgmii";

+	nvmem-cells = <&eth_mac>;
+	nvmem-cell-names = "mac-address";
+
 	amlogic,tx-delay-ns = <2>;

 	mdio {

-- 
2.53.0

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
  2026-10-11 17:17   ` Fil Dunsky via B4 Relay
@ 2026-10-11 17:24     ` sashiko-bot
  -1 siblings, 0 replies; 11+ messages in thread
From: sashiko-bot @ 2026-10-11 17:24 UTC (permalink / raw)
  To: Fil Dunsky; +Cc: neil.armstrong, robh, linux-amlogic, conor+dt, devicetree

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] net: of_get_mac_address_nvmem() fails due to 16-byte cell
--

commit 33c286acfab990fb62603385b64de76b3bd20dfe
Author: Fil Dunsky <filipp.dunsky@gmail.com>

arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

This commit updates the meson-gxbb-odroidc2 device tree to read the Ethernet
MAC address from the eFuse nvmem cell instead of relying on the bootloader.
It links the ethmac node to the existing eth_mac nvmem cell using standard
properties.

> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 5943bc810678e..639b97ad515c0 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -230,6 +230,9 @@ &ethmac {
>  	phy-handle = <&eth_phy0>;
>  	phy-mode = "rgmii";
>  
> +	nvmem-cells = <&eth_mac>;
> +	nvmem-cell-names = "mac-address";

[Severity: Medium]
Will this actually read the MAC address successfully? The network core strict
checks nvmem cells for MAC addresses to ensure they are exactly 6 bytes.

Looking at the eth_mac node defined in meson-gx.dtsi:

		eth_mac: eth-mac@34 {
			reg = <0x34 0x10>;
		};

This cell has a length of 16 bytes (0x10).

When the stmmac driver probes, it eventually calls of_get_mac_address_nvmem()
in net/core/of_net.c, which enforces this check:

	if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
		kfree(mac);
		return -EINVAL;
	}

Because 16 does not equal ETH_ALEN, this unconditionally returns -EINVAL. It
seems the driver will fall back to a bootloader-programmed or random MAC
address instead, which might be why it appeared to work during testing.

Could we adjust the device tree to point to a 6-byte cell instead?

> +
>  	amlogic,tx-delay-ns = <2>;
>  
>  	mdio {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-odroidc2-dts-v1-0-f9f0e779af88@gmail.com?part=1

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
@ 2026-10-11 17:24     ` sashiko-bot
  0 siblings, 0 replies; 11+ messages in thread
From: sashiko-bot @ 2026-10-11 17:24 UTC (permalink / raw)
  To: Fil Dunsky; +Cc: neil.armstrong, robh, linux-amlogic, conor+dt, devicetree

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] net: of_get_mac_address_nvmem() fails due to 16-byte cell
--

commit 33c286acfab990fb62603385b64de76b3bd20dfe
Author: Fil Dunsky <filipp.dunsky@gmail.com>

arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

This commit updates the meson-gxbb-odroidc2 device tree to read the Ethernet
MAC address from the eFuse nvmem cell instead of relying on the bootloader.
It links the ethmac node to the existing eth_mac nvmem cell using standard
properties.

> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 5943bc810678e..639b97ad515c0 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -230,6 +230,9 @@ &ethmac {
>  	phy-handle = <&eth_phy0>;
>  	phy-mode = "rgmii";
>  
> +	nvmem-cells = <&eth_mac>;
> +	nvmem-cell-names = "mac-address";

[Severity: Medium]
Will this actually read the MAC address successfully? The network core strict
checks nvmem cells for MAC addresses to ensure they are exactly 6 bytes.

Looking at the eth_mac node defined in meson-gx.dtsi:

		eth_mac: eth-mac@34 {
			reg = <0x34 0x10>;
		};

This cell has a length of 16 bytes (0x10).

When the stmmac driver probes, it eventually calls of_get_mac_address_nvmem()
in net/core/of_net.c, which enforces this check:

	if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
		kfree(mac);
		return -EINVAL;
	}

Because 16 does not equal ETH_ALEN, this unconditionally returns -EINVAL. It
seems the driver will fall back to a bootloader-programmed or random MAC
address instead, which might be why it appeared to work during testing.

Could we adjust the device tree to point to a 6-byte cell instead?

> +
>  	amlogic,tx-delay-ns = <2>;
>  
>  	mdio {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-odroidc2-dts-v1-0-f9f0e779af88@gmail.com?part=1

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED
  2026-10-11 17:17 ` Fil Dunsky via B4 Relay
  (?)
@ 2026-10-11 17:17   ` Fil Dunsky via B4 Relay
  -1 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky via B4 Relay @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

From: Fil Dunsky <filipp.dunsky@gmail.com>

Replace the legacy label on the blue status LED with the standard
color and function properties, following what the other Amlogic boards
already do.  The LED then shows up with a generic blue:status name
instead of the board-specific c2:blue:alive.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 639b97ad5..5f0cd2a71 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -9,6 +9,7 @@
 
 #include "meson-gxbb.dtsi"
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/sound/meson-aiu.h>
 
 / {
@@ -51,7 +52,8 @@ usb_otg_pwr: regulator-usb-pwrs {
 	leds {
 		compatible = "gpio-leds";
 		led-blue {
-			label = "c2:blue:alive";
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_STATUS;
 			gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
 			linux,default-trigger = "heartbeat";
 			default-state = "off";

-- 
2.53.0



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED
@ 2026-10-11 17:17   ` Fil Dunsky via B4 Relay
  0 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

Replace the legacy label on the blue status LED with the standard
color and function properties, following what the other Amlogic boards
already do.  The LED then shows up with a generic blue:status name
instead of the board-specific c2:blue:alive.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 639b97ad5..5f0cd2a71 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -9,6 +9,7 @@
 
 #include "meson-gxbb.dtsi"
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/sound/meson-aiu.h>
 
 / {
@@ -51,7 +52,8 @@ usb_otg_pwr: regulator-usb-pwrs {
 	leds {
 		compatible = "gpio-leds";
 		led-blue {
-			label = "c2:blue:alive";
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_STATUS;
 			gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
 			linux,default-trigger = "heartbeat";
 			default-state = "off";

-- 
2.53.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED
@ 2026-10-11 17:17   ` Fil Dunsky via B4 Relay
  0 siblings, 0 replies; 11+ messages in thread
From: Fil Dunsky via B4 Relay @ 2026-10-11 17:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
	Fil Dunsky

From: Fil Dunsky <filipp.dunsky@gmail.com>

Replace the legacy label on the blue status LED with the standard
color and function properties, following what the other Amlogic boards
already do.  The LED then shows up with a generic blue:status name
instead of the board-specific c2:blue:alive.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 639b97ad5..5f0cd2a71 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -9,6 +9,7 @@
 
 #include "meson-gxbb.dtsi"
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
 #include <dt-bindings/sound/meson-aiu.h>
 
 / {
@@ -51,7 +52,8 @@ usb_otg_pwr: regulator-usb-pwrs {
 	leds {
 		compatible = "gpio-leds";
 		led-blue {
-			label = "c2:blue:alive";
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_STATUS;
 			gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
 			linux,default-trigger = "heartbeat";
 			default-state = "off";

-- 
2.53.0




^ permalink raw reply related	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2026-10-11 17:24 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-11 17:17 [PATCH 0/2] arm64: dts: meson-gxbb-odroidc2: eFuse MAC address and LED properties Fil Dunsky via B4 Relay
2026-10-11 17:17 ` Fil Dunsky
2026-10-11 17:17 ` Fil Dunsky via B4 Relay
2026-10-11 17:17 ` [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse Fil Dunsky via B4 Relay
2026-10-11 17:17   ` Fil Dunsky
2026-10-11 17:17   ` Fil Dunsky via B4 Relay
2026-10-11 17:24   ` sashiko-bot
2026-10-11 17:24     ` sashiko-bot
2026-10-11 17:17 ` [PATCH 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED Fil Dunsky via B4 Relay
2026-10-11 17:17   ` Fil Dunsky
2026-10-11 17:17   ` Fil Dunsky via B4 Relay

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.