Re: [PATCH v3 2/2] nvmem: airoha: Add support for SMC eFUSE

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing device tree node linkage for NVMEM devices causes DT cell parsing failure and consumer resolution errors.
- [Low] Multiple unnamed regmaps registered on the same device cause debugfs collisions.
--

commit 50a12b4fbba5f61d8cd4d5c2c71e0f517760d0ef
Author: Christian Marangi <ansuelsmth@gmail.com>

nvmem: airoha: Add support for SMC eFUSE

This commit adds support for SMC eFUSE on the AN7581 SoC. It reads
calibration and specific SoC information via SMC commands, while
relying on ATF to validate the data and reject protected reads.

> diff --git a/drivers/nvmem/airoha-smc-efuses.c b/drivers/nvmem/airoha-smc-efuses.c
> new file mode 100644
> index 0000000000000..bb279d1495196
> --- /dev/null
> +++ b/drivers/nvmem/airoha-smc-efuses.c
[ ... ]
> +static int airoha_efuse_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int ret;
> +
> +	for_each_child_of_node_scoped(dev->of_node, child) {
[ ... ]
> +		priv->bank_index = bank;
> +
> +		regmap = devm_regmap_init(dev, NULL, priv,
> +					  &airoha_efuse_regmap_config);

Is there a risk of debugfs collisions here? devm_regmap_init() is called
for each eFuse bank using the same parent dev.

Since airoha_efuse_regmap_config does not define a name, will the regmap
core attempt to create duplicate debugfs directories under the parent
device's name, triggering a warning?

> +		if (IS_ERR(regmap))
> +			return PTR_ERR(regmap);
> +
> +		airoha_nvmem_config.priv = regmap;
> +		airoha_nvmem_config.dev = dev;
> +		airoha_nvmem_config.id = bank;
> +		nvmem = devm_nvmem_register(dev, &airoha_nvmem_config);

Does this sequence break NVMEM consumer resolution and device tree cell parsing?

The airoha_nvmem_config.of_node field is not set, so the NVMEM core will
default to using the parent device's of_node. This means consumers
requesting the child bank via a phandle might fail to find it, and the
NVMEM core might incorrectly parse the parent node's properties instead of
the child's cells.

If we assign airoha_nvmem_config.of_node = child, could this lead to a
use-after-free?

The for_each_child_of_node_scoped() macro automatically drops the reference
to child at the end of the loop, and the NVMEM subsystem does not acquire
its own reference when copying config.of_node. Does the driver need to
explicitly call of_node_get(child) and handle cleanup on unbind?

> +		if (IS_ERR(nvmem))
> +			return PTR_ERR(nvmem);
> +	}
> +
> +	return 0;
> +}

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