Re: [PATCH v3 2/3] nvmem: lan9662-otp: add support for LAN969x

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver mutates a shared static global structure (`otp_config`) during its `probe()` function, creating a data race on concurrent probes.
--

commit 084765687704216b34f261a961d208c0c6497f50
Author: Horatiu Vultur <horatiu.vultur@microchip.com>

nvmem: lan9662-otp: add support for LAN969x

This commit adds support for the Microchip LAN969x to the lan9662-otp driver.
It relies on the existing control logic while allowing the OTP size to vary
based on device tree match data.

> diff --git a/drivers/nvmem/lan9662-otpc.c b/drivers/nvmem/lan9662-otpc.c
> index 56fc19f092a7f..62d1d6381bf88 100644
> --- a/drivers/nvmem/lan9662-otpc.c
> +++ b/drivers/nvmem/lan9662-otpc.c

[ ... ]

> @@ -196,6 +194,7 @@ static int lan9662_otp_probe(struct platform_device *pdev)
>  
>  	otp_config.priv = otp;
>  	otp_config.dev = dev;
> +	otp_config.size = (uintptr_t) device_get_match_data(dev);

Does modifying the static otp_config structure during probe create a data
race?

If multiple device instances are probed concurrently, threads could race to
update these fields. This could lead to one instance being registered with
another's private data before devm_nvmem_register() creates its internal
copy.

If that happens and the latter device is unbound, its devm-managed memory is
freed, which could result in a use-after-free when the first device attempts
to access the nvmem interface.

Would it be safer to allocate the nvmem_config structure locally on the
stack within the probe function instead of using a global static structure?

>  
>  	nvmem = devm_nvmem_register(dev, &otp_config);
>

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