[PATCH v5] iio: chemical: sps30: Replace manual locking with RAII locking

[PATCH v5] iio: chemical: sps30: Replace manual locking with RAII locking

[Maxwell Doose]

Replace manual mutex_lock() and mutex_unlock() calls with the much newer
guard(mutex)() and scoped_guard() macros to enable RAII patterns,
modernize the driver, and to increase readability.

Move mutex locking into sps30_do_meas() and tune it up to use guard()(),
as every caller takes the lock anyways.

Signed-off-by: Maxwell Doose <m32285159@gmail.com>
---
v2:
 - Switch over some scoped_guard()s to guard(mutex)() per David's
   suggestion.
 - Remove redundant whitespace per Andy's suggestion.
 - Add new wrapper sps30_do_meas() per Andy's suggestion (see commit
   message).
 - Add Joshua's RB
   (link: https://lore.kernel.org/linux-iio/CAKqfh0FWig8mRR-xhvnfcFeSinR6RySyPaf9Gbpb6WU+diiiUQ@mail.gmail.com/T/#t)

v3:
 - Remove sps30_do_meas() wrapper per Andy's suggestion.
 - Remove Joshua's RB (major changes).

v4:
 - Move mutex locking into sps30_do_meas().

v5:
 - Tune up commit message to be more specific about sps30_do_meas()
   locking.
 - Fix up some stray whitespace.

 drivers/iio/chemical/sps30.c | 24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/iio/chemical/sps30.c b/drivers/iio/chemical/sps30.c
index a934bf0298dd..8e15baa31423 100644
--- a/drivers/iio/chemical/sps30.c
+++ b/drivers/iio/chemical/sps30.c
@@ -5,6 +5,7 @@
  * Copyright (c) Tomasz Duszynski <tduszyns@gmail.com>
  */
 
+#include <linux/cleanup.h>
 #include <linux/crc8.h>
 #include <linux/delay.h>
 #include <linux/i2c.h>
@@ -69,6 +70,8 @@ static int sps30_do_meas(struct sps30_state *state, s32 *data, int size)
 {
 	int i, ret;
 
+	guard(mutex)(&state->lock);
+
 	if (state->state == RESET) {
 		ret = state->ops->start_meas(state);
 		if (ret)
@@ -111,9 +114,7 @@ static irqreturn_t sps30_trigger_handler(int irq, void *p)
 		aligned_s64 ts;
 	} scan;
 
-	mutex_lock(&state->lock);
 	ret = sps30_do_meas(state, scan.data, ARRAY_SIZE(scan.data));
-	mutex_unlock(&state->lock);
 	if (ret)
 		goto err;
 
@@ -136,7 +137,6 @@ static int sps30_read_raw(struct iio_dev *indio_dev,
 	case IIO_CHAN_INFO_PROCESSED:
 		switch (chan->type) {
 		case IIO_MASSCONCENTRATION:
-			mutex_lock(&state->lock);
 			/* read up to the number of bytes actually needed */
 			switch (chan->channel2) {
 			case IIO_MOD_PM1:
@@ -152,7 +152,6 @@ static int sps30_read_raw(struct iio_dev *indio_dev,
 				ret = sps30_do_meas(state, data, 4);
 				break;
 			}
-			mutex_unlock(&state->lock);
 			if (ret)
 				return ret;
 
@@ -197,9 +196,9 @@ static ssize_t start_cleaning_store(struct device *dev,
 	if (kstrtoint(buf, 0, &val) || val != 1)
 		return -EINVAL;
 
-	mutex_lock(&state->lock);
+	guard(mutex)(&state->lock);
+
 	ret = state->ops->clean_fan(state);
-	mutex_unlock(&state->lock);
 	if (ret)
 		return ret;
 
@@ -215,9 +214,9 @@ static ssize_t cleaning_period_show(struct device *dev,
 	__be32 val;
 	int ret;
 
-	mutex_lock(&state->lock);
+	guard(mutex)(&state->lock);
+
 	ret = state->ops->read_cleaning_period(state, &val);
-	mutex_unlock(&state->lock);
 	if (ret)
 		return ret;
 
@@ -238,12 +237,11 @@ static ssize_t cleaning_period_store(struct device *dev, struct device_attribute
 	    (val > SPS30_AUTO_CLEANING_PERIOD_MAX))
 		return -EINVAL;
 
-	mutex_lock(&state->lock);
+	guard(mutex)(&state->lock);
+
 	ret = state->ops->write_cleaning_period(state, cpu_to_be32(val));
-	if (ret) {
-		mutex_unlock(&state->lock);
+	if (ret)
 		return ret;
-	}
 
 	msleep(20);
 
@@ -256,8 +254,6 @@ static ssize_t cleaning_period_store(struct device *dev, struct device_attribute
 		dev_warn(dev,
 			 "period changed but reads will return the old value\n");
 
-	mutex_unlock(&state->lock);
-
 	return len;
 }
 
-- 
2.54.0

Re: [PATCH v5] iio: chemical: sps30: Replace manual locking with RAII locking

[Jonathan Cameron]

On Sat, 23 May 2026 13:15:36 -0500
Maxwell Doose <m32285159@gmail.com> wrote:

> Replace manual mutex_lock() and mutex_unlock() calls with the much newer
> guard(mutex)() and scoped_guard() macros to enable RAII patterns,

There isn't any scoped_guard() left in here.  I'll tweak

> modernize the driver, and to increase readability.
> 
> Move mutex locking into sps30_do_meas() and tune it up to use guard()(),
> as every caller takes the lock anyways.
> 
> Signed-off-by: Maxwell Doose <m32285159@gmail.com>

Applied.

Thanks

Jonathan

Re: [PATCH v5] iio: chemical: sps30: Replace manual locking with RAII locking

[Andy Shevchenko]

On Sat, May 23, 2026 at 01:15:36PM -0500, Maxwell Doose wrote:
> Replace manual mutex_lock() and mutex_unlock() calls with the much newer
> guard(mutex)() and scoped_guard() macros to enable RAII patterns,
> modernize the driver, and to increase readability.
> 
> Move mutex locking into sps30_do_meas() and tune it up to use guard()(),
> as every caller takes the lock anyways.

...

> -	mutex_lock(&state->lock);
> +	guard(mutex)(&state->lock);
> +
>  	ret = state->ops->write_cleaning_period(state, cpu_to_be32(val));
> -	if (ret) {
> -		mutex_unlock(&state->lock);
> +	if (ret)
>  		return ret;
> -	}
>  
>  	msleep(20);

Same question as per v4 (yes, I see that it was in the original code).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5] iio: chemical: sps30: Replace manual locking with RAII locking

[Jonathan Cameron]

On Tue, 2 Jun 2026 10:14:34 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Sat, May 23, 2026 at 01:15:36PM -0500, Maxwell Doose wrote:
> > Replace manual mutex_lock() and mutex_unlock() calls with the much newer
> > guard(mutex)() and scoped_guard() macros to enable RAII patterns,
> > modernize the driver, and to increase readability.
> > 
> > Move mutex locking into sps30_do_meas() and tune it up to use guard()(),
> > as every caller takes the lock anyways.  
> 
> ...
> 
> > -	mutex_lock(&state->lock);
> > +	guard(mutex)(&state->lock);
> > +
> >  	ret = state->ops->write_cleaning_period(state, cpu_to_be32(val));
> > -	if (ret) {
> > -		mutex_unlock(&state->lock);
> > +	if (ret)
> >  		return ret;
> > -	}
> >  
> >  	msleep(20);  
> 
> Same question as per v4 (yes, I see that it was in the original code).
> 
I relied to v4.  I think it is the correct thing to do as adds a penalty
for stupid userspace code and doesn't complicate the driver like other
solutions would do.

J