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

Since mcp47feb02_parse_fw() is only called from probe(), remove the lock.

Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Changes in v2:
- Remove the lock in mcp47feb02_parse_fw() suggested by Nuno Sá.
- Link to v1: https://lore.kernel.org/r/20260223-mcp47feb02-v1-1-41f80bdbbb45@gmail.com
---
 drivers/iio/dac/mcp47feb02.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/iio/dac/mcp47feb02.c b/drivers/iio/dac/mcp47feb02.c
index b218f0c3a0bd..08fb85359697 100644
--- a/drivers/iio/dac/mcp47feb02.c
+++ b/drivers/iio/dac/mcp47feb02.c
@@ -955,8 +955,6 @@ static int mcp47feb02_parse_fw(struct iio_dev *indio_dev,
 	u32 num_channels;
 	u8 chan_idx = 0;
 
-	guard(mutex)(&data->lock);
-
 	num_channels = device_get_child_node_count(dev);
 	if (num_channels > chip_features->phys_channels)
 		return dev_err_probe(dev, -EINVAL, "More channels than the chip supports\n");

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

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

On Wed, Feb 25, 2026 at 10:48:57PM +0800, Felix Gu wrote:
> The mcp47feb02_parse_fw() function uses data->lock, but the mutex was
> initialized after this function in probe path.
> 
> Since mcp47feb02_parse_fw() is only called from probe(), remove the lock.

But is it called early enough before anything that may trigger access to
'data'? Exempli gratia, IRQ handler in some cases may be triggered before
probe finished (is it the case here?).

-- 
With Best Regards,
Andy Shevchenko