All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rosen Penev" <rosenp@gmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCHv2] ARM: dts: BCM5301X: R7000: add nvram node
Date: Fri, 11 Sep 2026 20:49:52 +0000	[thread overview]
Message-ID: <20260911204953.703B61F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260911203522.105474-1-rosenp@gmail.com>

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

      reply	other threads:[~2026-09-11 20:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 20:35 [PATCHv2] ARM: dts: BCM5301X: R7000: add nvram node Rosen Penev
2026-09-11 20:49 ` sashiko-bot [this message]

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=20260911204953.703B61F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=rosenp@gmail.com \
    --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.