The mcp47feb02_parse_fw() function uses data->lock, but the mutex was
initialized after this function in probe path.

Fix this by moving devm_mutex_init() before mcp47feb02_parse_fw().

Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
 drivers/iio/dac/mcp47feb02.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/dac/mcp47feb02.c b/drivers/iio/dac/mcp47feb02.c
index b218f0c3a0bd..4ff5abcfecea 100644
--- a/drivers/iio/dac/mcp47feb02.c
+++ b/drivers/iio/dac/mcp47feb02.c
@@ -1131,14 +1131,14 @@ static int mcp47feb02_probe(struct i2c_client *client)
 
 	indio_dev->name = chip_features->name;
 
-	ret = mcp47feb02_parse_fw(indio_dev, chip_features);
-	if (ret)
-		return dev_err_probe(dev, ret, "Error parsing firmware data\n");
-
 	ret = devm_mutex_init(dev, &data->lock);
 	if (ret)
 		return ret;
 
+	ret = mcp47feb02_parse_fw(indio_dev, chip_features);
+	if (ret)
+		return dev_err_probe(dev, ret, "Error parsing firmware data\n");
+
 	ret = devm_regulator_get_enable_read_voltage(dev, "vdd");
 	if (ret < 0)
 		return ret;

---
base-commit: d4906ae14a5f136ceb671bb14cedbf13fa560da6
change-id: 20260223-mcp47feb02-e0bed17e198b

Best regards,
-- 
Felix Gu <ustc.gu@gmail.com>

On Mon, 2026-02-23 at 16:03 +0800, Felix Gu wrote:
> The mcp47feb02_parse_fw() function uses data->lock, but the mutex was
> initialized after this function in probe path.
> 
> Fix this by moving devm_mutex_init() before mcp47feb02_parse_fw().
> 
> Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
>  drivers/iio/dac/mcp47feb02.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/dac/mcp47feb02.c b/drivers/iio/dac/mcp47feb02.c
> index b218f0c3a0bd..4ff5abcfecea 100644
> --- a/drivers/iio/dac/mcp47feb02.c
> +++ b/drivers/iio/dac/mcp47feb02.c
> @@ -1131,14 +1131,14 @@ static int mcp47feb02_probe(struct i2c_client *client)
>  
>  	indio_dev->name = chip_features->name;
>  
> -	ret = mcp47feb02_parse_fw(indio_dev, chip_features);
> -	if (ret)
> -		return dev_err_probe(dev, ret, "Error parsing firmware data\n");
> -
>  	ret = devm_mutex_init(dev, &data->lock);
>  	if (ret)
>  		return ret;
>  
> +	ret = mcp47feb02_parse_fw(indio_dev, chip_features);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Error parsing firmware data\n");
> +

Actually I think the better fix is to not lock at all? Why do we need a lock around 
mcp47feb02_parse_fw() if it's only called from probe()?

- Nuno Sá
> 

On Mon, Feb 23, 2026 at 11:13:33AM +0000, Nuno Sá wrote:
> On Mon, 2026-02-23 at 16:03 +0800, Felix Gu wrote:
> > The mcp47feb02_parse_fw() function uses data->lock, but the mutex was
> > initialized after this function in probe path.

> Actually I think the better fix is to not lock at all? Why do we need a lock around 
> mcp47feb02_parse_fw() if it's only called from probe()?

+1! The lock should be called when it's required. Any explanations from the Git
history on it?

-- 
With Best Regards,
Andy Shevchenko

On Mon, Feb 23, 2026 at 04:03:34PM +0800, Felix Gu wrote:
> The mcp47feb02_parse_fw() function uses data->lock, but the mutex was
> initialized after this function in probe path.
> 
> Fix this by moving devm_mutex_init() before mcp47feb02_parse_fw().

There are several patches from you lately. Are you sure the version is correct,
id est this one is indeed v1? Sorry, I'm a bit lost.

-- 
With Best Regards,
Andy Shevchenko

> There are several patches from you lately. Are you sure the version is correct,
> id est this one is indeed v1? Sorry, I'm a bit lost.
>
Hi Andy,
This is V1.
It seems b4 doesn't include V1 in the subject prefix by default.

Best regards,
Felix