Re: [PATCH v2] iio: accel: bmc150: use guard(mutex) for mutex handling

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 20 May 2026 11:12:47 +0100
Gabriel Rondon <grondon@gmail.com> wrote:

> Replace manual mutex_lock()/mutex_unlock() pairs with guard(mutex)
> and scoped_guard() from cleanup.h. This simplifies error paths by
> removing the need for explicit unlock calls before returning.
> 
> Most converted functions hold the lock for their entire body, so
> guard(mutex) applies directly. bmc150_accel_trigger_handler() only
> holds the lock around a single register read, so scoped_guard() is
> used there to keep the lock scope unchanged.
> 
> Signed-off-by: Gabriel Rondon <grondon@gmail.com>
So sashiko reports a load of preexisting issues (I haven't checked them
but it tends to be right most of the time). It spotted one issue in your
changes that i missed.

The only other 'this patch' thing was scoped_guard() + gotos. The particular
case you have is fine so don't worry about that.


>  static ssize_t bmc150_accel_get_fifo_state(struct device *dev,
> @@ -860,13 +848,10 @@ static ssize_t bmc150_accel_get_fifo_state(struct device *dev,
>  {
>  	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>  	struct bmc150_accel_data *data = iio_priv(indio_dev);
> -	bool state;
>  
> -	mutex_lock(&data->mutex);
> -	state = data->fifo_mode;
This cast an integer to a bool.   So 0x40 -> true.
> -	mutex_unlock(&data->mutex);
> +	guard(mutex)(&data->mutex);
>  
> -	return sysfs_emit(buf, "%d\n", state);
> +	return sysfs_emit(buf, "%d\n", data->fifo_mode);
This will just print that 0x40 (in decimal) whereas should be 0 or 1.
I'd suggest data->fifo_mode ? 1 : 0 in this call.

>  }
>