From: sashiko-bot@kernel.org
To: "Fil Dunsky" <filipp.dunsky@gmail.com>
Cc: neil.armstrong@linaro.org, robh@kernel.org,
linux-amlogic@lists.infradead.org, conor+dt@kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
Date: Sun, 11 Oct 2026 17:24:33 +0000 [thread overview]
Message-ID: <sashiko-outbox-167345@kernel.org> (raw)
In-Reply-To: <20261011-odroidc2-dts-v1-1-f9f0e779af88@gmail.com>
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 @@ ðmac {
> phy-handle = <ð_phy0>;
> phy-mode = "rgmii";
>
> + nvmem-cells = <ð_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
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Fil Dunsky" <filipp.dunsky@gmail.com>
Cc: neil.armstrong@linaro.org, robh@kernel.org,
linux-amlogic@lists.infradead.org, conor+dt@kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: meson-gxbb-odroidc2: read the Ethernet MAC address from eFuse
Date: Sun, 11 Oct 2026 17:24:33 +0000 [thread overview]
Message-ID: <sashiko-outbox-167345@kernel.org> (raw)
In-Reply-To: <20261011-odroidc2-dts-v1-1-f9f0e779af88@gmail.com>
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 @@ ðmac {
> phy-handle = <ð_phy0>;
> phy-mode = "rgmii";
>
> + nvmem-cells = <ð_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
next prev parent reply other threads:[~2026-10-11 17:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-167345@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=filipp.dunsky@gmail.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.