[PATCHv2] ARM: dts: BCM5301X: R7000: add nvram node

[PATCHv2] ARM: dts: BCM5301X: R7000: add nvram node

[Rosen Penev]

Add it and set MAC for gmac2, to avoid having to handle in userspaace.

nvram size found from a random bootlog online.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 v2: set gmac2 instead.
 .../boot/dts/broadcom/bcm4709-netgear-r7000.dts    | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
index 24ba8f8f9bf3..6ea845f3ac1d 100644
--- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
@@ -25,6 +25,15 @@ memory@0 {
 		      <0x88000000 0x08000000>;
 	};
 
+	nvram@1c080000 {
+		compatible = "brcm,nvram";
+		reg = <0x1c080000 0x180000>;
+
+		et0macaddr: et0macaddr {
+			#nvmem-cell-cells = <1>;
+		};
+	};
+
 	leds {
 		compatible = "gpio-leds";
 
@@ -104,3 +113,8 @@ &usb3 {
 &usb3_phy {
 	status = "okay";
 };
+
+&gmac2 {
+	nvmem-cells = <&et0macaddr 0>;
+	nvmem-cell-names = "mac-address";
+};
-- 
2.55.0

Re: [PATCHv2] ARM: dts: BCM5301X: R7000: add nvram node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but a malformed NVRAM variable causes the entire brcm_nvram driver to fail probe.
--

commit 1557e665e36010df6961b214ff9a34a470e52acd
Author: Rosen Penev <rosenp@gmail.com>

ARM: dts: BCM5301X: R7000: add nvram node

This commit adds the nvram node and sets the MAC address for gmac2 
to avoid userspace handling.

> diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
> index 24ba8f8f9bf36..6ea845f3ac1d3 100644
> --- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
> @@ -25,6 +25,15 @@ memory@0 {
>  		      <0x88000000 0x08000000>;
>  	};
>  
> +	nvram@1c080000 {
> +		compatible = "brcm,nvram";
> +		reg = <0x1c080000 0x180000>;
> +
> +		et0macaddr: et0macaddr {
> +			#nvmem-cell-cells = <1>;
> +		};
> +	};
> +

[Severity: High]
This isn't a bug introduced by this patch, but enabling this driver on
more devices exposes a pre-existing issue in the brcm_nvram driver if
the NVRAM contents are malformed.

Could a malformed NVRAM variable cause the entire brcm_nvram driver to 
fail probe?

Looking at brcm_nvram_add_cells() in drivers/nvmem/brcm_nvram.c:

drivers/nvmem/brcm_nvram.c:brcm_nvram_add_cells() {
    ...
    for (var = data; var < data + len && *var; var += strlen(var) + 1) {
        eq = strchr(var, '=');
        if (!eq)
            break;
    ...
}

If a string lacks an '=' character, the loop breaks early, but does not
update priv->ncells to the actual number of successfully processed cells.

This leaves the trailing cell structures zero-initialized (name == NULL).

When passed to devm_nvmem_register(), nvmem_add_cells() calls
kstrdup_const(NULL) for these uninitialized cells, which returns -ENOMEM
and causes the entire driver probe to fail.

Since this breaks dependent devices like Ethernet controllers needing MAC
addresses, should the driver be updated to handle malformed strings more
gracefully?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911203522.105474-1-rosenp@gmail.com?part=1