[PATCH v2] iio: chemical: scd30: Use devm_mutex_init() over non-devm mutex_init()

[PATCH v2] iio: chemical: scd30: Use devm_mutex_init() over non-devm mutex_init()

[Maxwell Doose]

The current code uses mutex_init() instead of devm_mutex_init(), which
is incorrect as the rest of the file uses the devm automatic resource
management API. Fix this so that the mutex is set up in the same way as
the rest of the device data structure.

Signed-off-by: Maxwell Doose <m32285159@gmail.com>
---
 v2:
 - Drop fixes tag per Jonathan's suggestion.
 - Replace dev_err_probe() with return -ENOMEM per Jonathan and Andy's
   suggestions.

 drivers/iio/chemical/scd30_core.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/chemical/scd30_core.c b/drivers/iio/chemical/scd30_core.c
index db5cc295aeab..198add58affd 100644
--- a/drivers/iio/chemical/scd30_core.c
+++ b/drivers/iio/chemical/scd30_core.c
@@ -714,7 +714,10 @@ int scd30_probe(struct device *dev, int irq, const char *name, void *priv,
 	state->pressure_comp = SCD30_PRESSURE_COMP_DEFAULT;
 	state->meas_interval = SCD30_MEAS_INTERVAL_DEFAULT;
 	state->command = command;
-	mutex_init(&state->lock);
+	ret = devm_mutex_init(dev, &state->lock);
+	if (ret)
+		return -ENOMEM;
+
 	init_completion(&state->meas_ready);
 
 	dev_set_drvdata(dev, indio_dev);
-- 
2.54.0

Re: [PATCH v2] iio: chemical: scd30: Use devm_mutex_init() over non-devm mutex_init()

[Joshua Crofts]

On Thu, 4 Jun 2026 at 15:27, Maxwell Doose <m32285159@gmail.com> wrote:
>
> The current code uses mutex_init() instead of devm_mutex_init(), which
> is incorrect as the rest of the file uses the devm automatic resource
> management API. Fix this so that the mutex is set up in the same way as
> the rest of the device data structure.
>
> Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> ---

Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>

Re: [PATCH v2] iio: chemical: scd30: Use devm_mutex_init() over non-devm mutex_init()

[David Lechner]

On Thu, Jun 4, 2026 at 3:17 PM Maxwell Doose <m32285159@gmail.com> wrote:
>
> The current code uses mutex_init() instead of devm_mutex_init(), which
> is incorrect as the rest of the file uses the devm automatic resource
> management API. Fix this so that the mutex is set up in the same way as
> the rest of the device data structure.
>
> Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> ---
>  v2:
>  - Drop fixes tag per Jonathan's suggestion.
>  - Replace dev_err_probe() with return -ENOMEM per Jonathan and Andy's
>    suggestions.
>
>  drivers/iio/chemical/scd30_core.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/chemical/scd30_core.c b/drivers/iio/chemical/scd30_core.c
> index db5cc295aeab..198add58affd 100644
> --- a/drivers/iio/chemical/scd30_core.c
> +++ b/drivers/iio/chemical/scd30_core.c
> @@ -714,7 +714,10 @@ int scd30_probe(struct device *dev, int irq, const char *name, void *priv,
>         state->pressure_comp = SCD30_PRESSURE_COMP_DEFAULT;
>         state->meas_interval = SCD30_MEAS_INTERVAL_DEFAULT;
>         state->command = command;
> -       mutex_init(&state->lock);
> +       ret = devm_mutex_init(dev, &state->lock);
> +       if (ret)
> +               return -ENOMEM;

Why are we ignoring ret?

I would expect:

              return ret;

> +
>         init_completion(&state->meas_ready);
>
>         dev_set_drvdata(dev, indio_dev);
> --
> 2.54.0
>

Re: [PATCH v2] iio: chemical: scd30: Use devm_mutex_init() over non-devm mutex_init()

[Maxwell Doose]

On Thu, Jun 4, 2026 at 11:20 AM David Lechner <dlechner@baylibre.com> wrote:
>
> On Thu, Jun 4, 2026 at 3:17 PM Maxwell Doose <m32285159@gmail.com> wrote:
> >
> > The current code uses mutex_init() instead of devm_mutex_init(), which
> > is incorrect as the rest of the file uses the devm automatic resource
> > management API. Fix this so that the mutex is set up in the same way as
> > the rest of the device data structure.
> >
> > Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> > ---
> >  v2:
> >  - Drop fixes tag per Jonathan's suggestion.
> >  - Replace dev_err_probe() with return -ENOMEM per Jonathan and Andy's
> >    suggestions.
> >
> >  drivers/iio/chemical/scd30_core.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/chemical/scd30_core.c b/drivers/iio/chemical/scd30_core.c
> > index db5cc295aeab..198add58affd 100644
> > --- a/drivers/iio/chemical/scd30_core.c
> > +++ b/drivers/iio/chemical/scd30_core.c
> > @@ -714,7 +714,10 @@ int scd30_probe(struct device *dev, int irq, const char *name, void *priv,
> >         state->pressure_comp = SCD30_PRESSURE_COMP_DEFAULT;
> >         state->meas_interval = SCD30_MEAS_INTERVAL_DEFAULT;
> >         state->command = command;
> > -       mutex_init(&state->lock);
> > +       ret = devm_mutex_init(dev, &state->lock);
> > +       if (ret)
> > +               return -ENOMEM;
>
> Why are we ignoring ret?
>
> I would expect:
>
>               return ret;
>

Gah, I must've Jonathan's + Andy's comments get to my head (He said it
should likely only return -ENOMEM) :(
I don't know if he'll want to tweak while applying or if I should just
go back and resubmit.

Re: [PATCH v2] iio: chemical: scd30: Use devm_mutex_init() over non-devm mutex_init()

[Andy Shevchenko]

On Thu, Jun 04, 2026 at 11:21:07AM -0500, Maxwell Doose wrote:
> On Thu, Jun 4, 2026 at 11:20 AM David Lechner <dlechner@baylibre.com> wrote:
> > On Thu, Jun 4, 2026 at 3:17 PM Maxwell Doose <m32285159@gmail.com> wrote:

...

> > > +       ret = devm_mutex_init(dev, &state->lock);
> > > +       if (ret)
> > > +               return -ENOMEM;
> >
> > Why are we ignoring ret?
> >
> > I would expect:
> >
> >               return ret;
> 
> Gah, I must've Jonathan's + Andy's comments get to my head (He said it
> should likely only return -ENOMEM) :(
> I don't know if he'll want to tweak while applying or if I should just
> go back and resubmit.

What we meant is that:

- devm_mutex_init() may return only -ENOMEM as of today
- dev_err_probe() will ignore (print nothing) when err == -ENOMEM

It has nothing to do with the caller, we explained how callee do.
TL;DR: it should be simple return ret; as Jonathan said already.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] iio: chemical: scd30: Use devm_mutex_init() over non-devm mutex_init()

[Jonathan Cameron]

On Thu, 4 Jun 2026 11:21:07 -0500
Maxwell Doose <m32285159@gmail.com> wrote:

> On Thu, Jun 4, 2026 at 11:20 AM David Lechner <dlechner@baylibre.com> wrote:
> >
> > On Thu, Jun 4, 2026 at 3:17 PM Maxwell Doose <m32285159@gmail.com> wrote:  
> > >
> > > The current code uses mutex_init() instead of devm_mutex_init(), which
> > > is incorrect as the rest of the file uses the devm automatic resource
> > > management API. Fix this so that the mutex is set up in the same way as
> > > the rest of the device data structure.
> > >
> > > Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> > > ---
> > >  v2:
> > >  - Drop fixes tag per Jonathan's suggestion.
> > >  - Replace dev_err_probe() with return -ENOMEM per Jonathan and Andy's
> > >    suggestions.
> > >
> > >  drivers/iio/chemical/scd30_core.c | 5 ++++-
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iio/chemical/scd30_core.c b/drivers/iio/chemical/scd30_core.c
> > > index db5cc295aeab..198add58affd 100644
> > > --- a/drivers/iio/chemical/scd30_core.c
> > > +++ b/drivers/iio/chemical/scd30_core.c
> > > @@ -714,7 +714,10 @@ int scd30_probe(struct device *dev, int irq, const char *name, void *priv,
> > >         state->pressure_comp = SCD30_PRESSURE_COMP_DEFAULT;
> > >         state->meas_interval = SCD30_MEAS_INTERVAL_DEFAULT;
> > >         state->command = command;
> > > -       mutex_init(&state->lock);
> > > +       ret = devm_mutex_init(dev, &state->lock);
> > > +       if (ret)
> > > +               return -ENOMEM;  
> >
> > Why are we ignoring ret?
> >
> > I would expect:
> >
> >               return ret;
> >  
> 
> Gah, I must've Jonathan's + Andy's comments get to my head (He said it
> should likely only return -ENOMEM) :(
> I don't know if he'll want to tweak while applying or if I should just
> go back and resubmit.

IIO is effectively closed for this cycle so plenty of time and I'm lazy
so please send a v3.

Jonathan