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

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

[Fil Dunsky via B4 Relay]

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

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

[Fil Dunsky via B4 Relay]

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>

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

[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>

[PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[Fil Dunsky via B4 Relay]

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

[PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[Fil Dunsky via B4 Relay]

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

[PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[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

[PATCH 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

[Fil Dunsky via B4 Relay]

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

[PATCH 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

[Fil Dunsky via B4 Relay]

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

[PATCH 2/2] arm64: dts: meson-gxbb-odroidc2: use color and function for the status LED

[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

Re: [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[sashiko-bot]

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

Re: [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse

[sashiko-bot]

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