devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be
marked as unusable and trigger errors on usage.

Add the missed check.

Fixes: 87a59548af95 ("leds: lp8860: Use new mutex guards to cleanup function exits")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Andrew Davis <afd@ti.com>
---
 drivers/leds/leds-lp8860.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
index 52b97c9f2a03567aa12d4f63a951593a5e7017d5..0962c00c215a11f555a7878a3b65824b5219a1fa 100644
--- a/drivers/leds/leds-lp8860.c
+++ b/drivers/leds/leds-lp8860.c
@@ -307,7 +307,9 @@ static int lp8860_probe(struct i2c_client *client)
 	led->client = client;
 	led->led_dev.brightness_set_blocking = lp8860_brightness_set;
 
-	devm_mutex_init(&client->dev, &led->lock);
+	ret = devm_mutex_init(&client->dev, &led->lock);
+	if (ret)
+		return dev_err_probe(&client->dev, ret, "Failed to initialize lock\n");
 
 	led->regmap = devm_regmap_init_i2c(client, &lp8860_regmap_config);
 	if (IS_ERR(led->regmap)) {

-- 
2.50.0

On Tue, 17 Jun 2025 19:08:13 +0200, Thomas Weißschuh wrote:
> devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be
> marked as unusable and trigger errors on usage.
> 
> Add the missed check.
> 
> 

Applied, thanks!

[2/3] leds: lp8860: Check return value of devm_mutex_init()
      commit: 426e0c8e8eed26b67bbbd138483bb5973724adae

--
Lee Jones [李琼斯]

Hi Lee,

On 2025-06-19 13:34:56+0100, Lee Jones wrote:
> On Tue, 17 Jun 2025 19:08:13 +0200, Thomas Weißschuh wrote:
> > devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be
> > marked as unusable and trigger errors on usage.
> > 
> > Add the missed check.
> 
> Applied, thanks!
> 
> [2/3] leds: lp8860: Check return value of devm_mutex_init()
>       commit: 426e0c8e8eed26b67bbbd138483bb5973724adae

Thanks, but (as mentioned in the cover letter) these patches should go
together through the mutex/locking tree.
Could you drop it on your side and give an Ack instead?


Thomas

On Thu, 19 Jun 2025, Thomas Weißschuh wrote:

> Hi Lee,
> 
> On 2025-06-19 13:34:56+0100, Lee Jones wrote:
> > On Tue, 17 Jun 2025 19:08:13 +0200, Thomas Weißschuh wrote:
> > > devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be
> > > marked as unusable and trigger errors on usage.
> > > 
> > > Add the missed check.
> > 
> > Applied, thanks!
> > 
> > [2/3] leds: lp8860: Check return value of devm_mutex_init()
> >       commit: 426e0c8e8eed26b67bbbd138483bb5973724adae
> 
> Thanks, but (as mentioned in the cover letter) these patches should go
> together through the mutex/locking tree.
> Could you drop it on your side and give an Ack instead?

There has to be good reasons to do this.

I didn't see any dependents or dependencies in this patch.

-- 
Lee Jones [李琼斯]

On 2025-06-25 10:04:39+0100, Lee Jones wrote:
> On Thu, 19 Jun 2025, Thomas Weißschuh wrote:
> > On 2025-06-19 13:34:56+0100, Lee Jones wrote:
> > > On Tue, 17 Jun 2025 19:08:13 +0200, Thomas Weißschuh wrote:
> > > > devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be
> > > > marked as unusable and trigger errors on usage.
> > > > 
> > > > Add the missed check.
> > > 
> > > Applied, thanks!
> > > 
> > > [2/3] leds: lp8860: Check return value of devm_mutex_init()
> > >       commit: 426e0c8e8eed26b67bbbd138483bb5973724adae
> > 
> > Thanks, but (as mentioned in the cover letter) these patches should go
> > together through the mutex/locking tree.
> > Could you drop it on your side and give an Ack instead?
> 
> There has to be good reasons to do this.
>
> I didn't see any dependents or dependencies in this patch.

Patch 3 depends on patch 1 and 2.

It will break the build for each instance of an ignored return value
of devm_mutex_init(). Therefore all such instances need to be resolved
before the patch can be applied.
So the patches can't go through different trees.

In theory we could fix the drivers in this cycle and then change
devm_mutex_init() in the next one. But new regressions are introduced
over and over. This patch is already in the third cycle...


Thomas

On Thu, 26 Jun 2025, Thomas Weißschuh wrote:

> On 2025-06-25 10:04:39+0100, Lee Jones wrote:
> > On Thu, 19 Jun 2025, Thomas Weißschuh wrote:
> > > On 2025-06-19 13:34:56+0100, Lee Jones wrote:
> > > > On Tue, 17 Jun 2025 19:08:13 +0200, Thomas Weißschuh wrote:
> > > > > devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be
> > > > > marked as unusable and trigger errors on usage.
> > > > > 
> > > > > Add the missed check.
> > > > 
> > > > Applied, thanks!
> > > > 
> > > > [2/3] leds: lp8860: Check return value of devm_mutex_init()
> > > >       commit: 426e0c8e8eed26b67bbbd138483bb5973724adae
> > > 
> > > Thanks, but (as mentioned in the cover letter) these patches should go
> > > together through the mutex/locking tree.
> > > Could you drop it on your side and give an Ack instead?
> > 
> > There has to be good reasons to do this.
> >
> > I didn't see any dependents or dependencies in this patch.
> 
> Patch 3 depends on patch 1 and 2.
> 
> It will break the build for each instance of an ignored return value
> of devm_mutex_init(). Therefore all such instances need to be resolved
> before the patch can be applied.
> So the patches can't go through different trees.
> 
> In theory we could fix the drivers in this cycle and then change
> devm_mutex_init() in the next one. But new regressions are introduced
> over and over. This patch is already in the third cycle...

Fair point.

Acked-by: Lee Jones <lee@kernel.org>

And patch removed from LEDs.

-- 
Lee Jones [李琼斯]