All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Loic Poulain" <loic.poulain@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v9 04/10] nvmem: layouts: Support fixed-layout as the nvmem device node itself
Date: Fri, 31 Jul 2026 16:01:19 +0000	[thread overview]
Message-ID: <20260731160120.9E9B81F00AC4@smtp.kernel.org> (raw)
In-Reply-To: <20260730-block-as-nvmem-v9-4-f72935817dbf@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Double-parsing of nvmem cells causes device probe failure when the provider node has `compatible = "fixed-layout"`.
--

--- Patch [4]: [PATCH v9 04/10] nvmem: layouts: Support fixed-layout as the nvmem device node itself ---
commit d3f11032479fe63790d2e2a677a2a7e3ebc199dc
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

nvmem: layouts: Support fixed-layout as the nvmem device node itself

This commit allows of_nvmem_layout_get_container() to fall back to the nvmem
device node itself if it is compatible with "fixed-layout". This enables the
cells to be parsed directly by nvmem_add_cells_from_fixed_layout() when no
child layout node is present.

> diff --git a/drivers/nvmem/layouts.c b/drivers/nvmem/layouts.c
> index b90584e1b99ea..efa631ce7283b 100644
> --- a/drivers/nvmem/layouts.c
> +++ b/drivers/nvmem/layouts.c
> @@ -167,7 +167,18 @@ static int nvmem_layout_bus_populate(struct nvmem_device *nvmem,
>  
>  struct device_node *of_nvmem_layout_get_container(struct nvmem_device *nvmem)
>  {
> -	return of_get_child_by_name(nvmem->dev.of_node, "nvmem-layout");
> +	struct device_node *np;
> +
> +	/* Search for nvmem-layout child */
> +	np = of_get_child_by_name(nvmem->dev.of_node, "nvmem-layout");
> +	if (np)
> +		return np;
> +
> +	/* The nvmem of_node is itself a fixed-layout node */
> +	if (of_device_is_compatible(nvmem->dev.of_node, "fixed-layout"))
> +		return of_node_get(nvmem->dev.of_node);

[Severity: High]
Will returning the provider's own device node here cause a double-parsing
issue and device probe failure due to sysfs attribute collisions?

In drivers/nvmem/core.c:nvmem_register(), both legacy parsing and
fixed-layout parsing are executed consecutively without checking for
duplication:

    if (config->add_legacy_fixed_of_cells) {
        rval = nvmem_add_cells_from_legacy_of(nvmem);
        if (rval)
            goto err_remove_cells;
    }

    rval = nvmem_add_cells_from_fixed_layout(nvmem);
    if (rval)
        goto err_remove_cells;

If a provider sets config->add_legacy_fixed_of_cells = true for backwards
compatibility, but the device tree uses the new "fixed-layout" compatible on
the provider node, both functions will parse the same of_node children.

Could this lead to duplicate cells being added to nvmem->cells, causing
nvmem_populate_sysfs_cells() to fail with -EEXIST?

> +
> +	return NULL;
>  }
>  EXPORT_SYMBOL_GPL(of_nvmem_layout_get_container);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-block-as-nvmem-v9-0-f72935817dbf@oss.qualcomm.com?part=4

  reply	other threads:[~2026-07-31 16:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 16:00 [PATCH v9 00/10] Support for block device NVMEM providers Loic Poulain
2026-07-30 16:00 ` [PATCH v9 01/10] dt-bindings: mmc: Document fixed-layout NVMEM provider support Loic Poulain
2026-07-30 17:30   ` Support for block device NVMEM providers bluez.test.bot
2026-07-31  8:39   ` [PATCH v9 01/10] dt-bindings: mmc: Document fixed-layout NVMEM provider support Bartosz Golaszewski
2026-07-31 16:01   ` sashiko-bot
2026-07-30 16:00 ` [PATCH v9 02/10] dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells Loic Poulain
2026-07-30 16:00 ` [PATCH v9 03/10] dt-bindings: bluetooth: qcom: Add NVMEM BD address cell Loic Poulain
2026-07-30 16:00 ` [PATCH v9 04/10] nvmem: layouts: Support fixed-layout as the nvmem device node itself Loic Poulain
2026-07-31 16:01   ` sashiko-bot [this message]
2026-07-30 16:00 ` [PATCH v9 05/10] block: partitions: of: Attach partition fwnode to the block device Loic Poulain
2026-07-31  8:40   ` Bartosz Golaszewski
2026-07-31 16:01   ` sashiko-bot
2026-07-30 16:00 ` [PATCH v9 06/10] block: implement NVMEM provider Loic Poulain
2026-07-31 16:01   ` sashiko-bot
2026-07-30 16:00 ` [PATCH v9 07/10] net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup Loic Poulain
2026-07-30 16:00 ` [PATCH v9 08/10] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval Loic Poulain
2026-07-31 16:01   ` sashiko-bot
2026-07-30 16:00 ` [PATCH v9 09/10] Bluetooth: qca: Set NVMEM BD address quirks when address is invalid Loic Poulain
2026-07-30 16:00 ` [PATCH v9 10/10] arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses Loic Poulain
2026-07-31 16:01   ` sashiko-bot

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=20260731160120.9E9B81F00AC4@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=loic.poulain@oss.qualcomm.com \
    --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.