Re: [PATCH v6 10/17] nvmem: microchip-otpc: nvmem: add emulation mode and OTP access validation

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Modifying a global static `nvmem_config` structure in the `probe()` function causes a data race if multiple device instances are bound concurrently.
--

--- Patch [10]: [PATCH v6 10/17] nvmem: microchip-otpc: nvmem: add emulation mode and OTP access validation ---
commit 055a4dec457440d76a4443758162d8aa873a40cc
Author: Varshini Rajendran <varshini.rajendran@microchip.com>

nvmem: microchip-otpc: nvmem: add emulation mode and OTP access validation

This commit adds validation for OTP memory accessibility and emulation mode
status during probe. It logs informational messages to help with debugging
when the boot packet is not configured or emulation mode is disabled.

> diff --git a/drivers/nvmem/microchip-otpc.c b/drivers/nvmem/microchip-otpc.c
> index a17f82afdc37d..6b0184423463e 100644
> --- a/drivers/nvmem/microchip-otpc.c
> +++ b/drivers/nvmem/microchip-otpc.c
[ ... ]
> @@ -343,7 +344,8 @@ static int mchp_otpc_probe(struct platform_device *pdev)
>  {
>  	struct nvmem_device *nvmem;
>  	struct mchp_otpc *otpc;
[ ... ]
>  	ret = mchp_otpc_init_packets_list(otpc, &size);
>  	if (ret)
>  		return ret;
>  
> +	if (!size) {
> +		dev_warn(otpc->dev, "Cannot access OTP memory\n");
> +		if (!emul_enable)
> +			dev_info(otpc->dev, "Boot packet not programmed and emulation mode disabled\n");
> +	}
> +
>  	mchp_nvmem_config.dev = otpc->dev;
>  	mchp_nvmem_config.add_legacy_fixed_of_cells = true;
>  	mchp_nvmem_config.size = size;
>  	mchp_nvmem_config.priv = otpc;
>  	nvmem = devm_nvmem_register(&pdev->dev, &mchp_nvmem_config);

[Severity: High]
This is a pre-existing issue, but does modifying the global static
mchp_nvmem_config structure here cause a data race?

If multiple instances of this driver probe concurrently, such as through
sysfs bind or multiple device tree nodes, one instance could overwrite the dev,
size, and priv fields of the global configuration structure before the other
instance completes devm_nvmem_register().

This could lead to the core nvmem subsystem storing the wrong priv pointer
for the device, which might result in incorrect register accesses or a
use-after-free during operations.

Should this configuration structure be copied to a local variable within
mchp_otpc_probe() to ensure the probe function is reentrant?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806074024.531259-1-varshini.rajendran@microchip.com?part=10