Replace manual mutex_lock/mutex_unlock pair with guard(mutex)
in bmc150_accel_buffer_predisable() and
bmc150_accel_buffer_postenable(). This ensures the mutex is
released on all return paths and allows returning directly
without a goto label.

Signed-off-by: Rajveer Chaudhari <rajveer.chaudhari.linux@gmail.com>
---
v3: stop initialising ret=0 at start, making clear about good path.
moved return ret up into the if (ret) {} block in
bmc150_accel_buffer_postenable().

v2: Cleaned mutex_unlock and goto in
bmc150_accel_buffer_postenable(),
Dropped Header alignment change.
---
 drivers/iio/accel/bmc150-accel-core.c | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
index 42ccf0316ce5..4772dc6fcee9 100644
--- a/drivers/iio/accel/bmc150-accel-core.c
+++ b/drivers/iio/accel/bmc150-accel-core.c
@@ -7,6 +7,7 @@
 #include <linux/module.h>
 #include <linux/i2c.h>
 #include <linux/interrupt.h>
+#include <linux/cleanup.h>
 #include <linux/delay.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
@@ -1480,20 +1481,20 @@ static int bmc150_accel_buffer_preenable(struct iio_dev *indio_dev)
 static int bmc150_accel_buffer_postenable(struct iio_dev *indio_dev)
 {
 	struct bmc150_accel_data *data = iio_priv(indio_dev);
-	int ret = 0;
+	int ret;
 
 	if (iio_device_get_current_mode(indio_dev) == INDIO_BUFFER_TRIGGERED)
 		return 0;
 
-	mutex_lock(&data->mutex);
+	guard(mutex)(&data->mutex);
 
 	if (!data->watermark)
-		goto out;
+		return 0;
 
 	ret = bmc150_accel_set_interrupt(data, BMC150_ACCEL_INT_WATERMARK,
 					 true);
 	if (ret)
-		goto out;
+		return ret;
 
 	data->fifo_mode = BMC150_ACCEL_FIFO_MODE_FIFO;
 
@@ -1502,12 +1503,10 @@ static int bmc150_accel_buffer_postenable(struct iio_dev *indio_dev)
 		data->fifo_mode = 0;
 		bmc150_accel_set_interrupt(data, BMC150_ACCEL_INT_WATERMARK,
 					   false);
+		return ret;
 	}
 
-out:
-	mutex_unlock(&data->mutex);
-
-	return ret;
+	return 0;
 }
 
 static int bmc150_accel_buffer_predisable(struct iio_dev *indio_dev)
@@ -1517,19 +1516,16 @@ static int bmc150_accel_buffer_predisable(struct iio_dev *indio_dev)
 	if (iio_device_get_current_mode(indio_dev) == INDIO_BUFFER_TRIGGERED)
 		return 0;
 
-	mutex_lock(&data->mutex);
+	guard(mutex)(&data->mutex);
 
 	if (!data->fifo_mode)
-		goto out;
+		return 0;
 
 	bmc150_accel_set_interrupt(data, BMC150_ACCEL_INT_WATERMARK, false);
 	__bmc150_accel_fifo_flush(indio_dev, BMC150_ACCEL_FIFO_LENGTH, false);
 	data->fifo_mode = 0;
 	bmc150_accel_fifo_set_mode(data);
 
-out:
-	mutex_unlock(&data->mutex);
-
 	return 0;
 }
 
-- 
2.53.0

On Thu, Mar 12, 2026 at 01:49:39PM +0530, Rajveer Chaudhari wrote:
> Replace manual mutex_lock/mutex_unlock pair with guard(mutex)
> in bmc150_accel_buffer_predisable() and
> bmc150_accel_buffer_postenable(). This ensures the mutex is
> released on all return paths and allows returning directly
> without a goto label.

> v2: Cleaned mutex_unlock and goto in
> bmc150_accel_buffer_postenable(),


> Dropped Header alignment change.

I don't understand why you can't do that as prerequisite. At some point we
probably go through them to fix, but since the new header is added, it makes
sense to put it to the proper order.

Same comment to other patches in the series.

-- 
With Best Regards,
Andy Shevchenko

On Thu, Mar 12, 2026 at 7:49 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> I don't understand why you can't do that as prerequisite. At some point we
> probably go through them to fix, but since the new header is added, it makes
> sense to put it to the proper order.

Hello Andy

Thanks for the review, as Waqar Hameed said earlier to not change
anything until they have
a consensus here.
Ref Link: https://lore.kernel.org/all/pndwlzk51j3.a.out@axis.com/

Do you want me to order the headers now in the new version?, I would
be happy to do that.

With Best Regards,
Rajveer Chaudhari

On Thu, Mar 12, 2026 at 09:57:33PM +0530, Rajveer Chaudhari wrote:
> On Thu, Mar 12, 2026 at 7:49 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > I don't understand why you can't do that as prerequisite. At some point we
> > probably go through them to fix, but since the new header is added, it makes
> > sense to put it to the proper order.
> 
> Thanks for the review, as Waqar Hameed said earlier to not change
> anything until they have
> a consensus here.
> Ref Link: https://lore.kernel.org/all/pndwlzk51j3.a.out@axis.com/
> 
> Do you want me to order the headers now in the new version?, I would
> be happy to do that.

In IIO we want to have the unified style across the drivers. WRT header
inclusions there are several expectations:
- headers are sorted
- IWYU principle is followed
- the IIO (and rarely some others) are grouped

OTOH we don't want to see the patch just for the same of this unification
as it adds just a churn (if driver is not under active development, it's
better to leave it alone for the maintainer's decision). Since you have
other patches in your series which introduce a new header, it's okay to
have a prerequisite to fix the ordering issues.


-- 
With Best Regards,
Andy Shevchenko

On Thu, Mar 12, 2026 at 21:57 +0530 Rajveer Chaudhari <rajveer.chaudhari.linux@gmail.com> wrote:

> On Thu, Mar 12, 2026 at 7:49 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
>>
>> I don't understand why you can't do that as prerequisite. At some point we
>> probably go through them to fix, but since the new header is added, it makes
>> sense to put it to the proper order.
>
> Hello Andy
>
> Thanks for the review, as Waqar Hameed said earlier to not change
> anything until they have
> a consensus here.
> Ref Link: https://lore.kernel.org/all/pndwlzk51j3.a.out@axis.com/
>
> Do you want me to order the headers now in the new version?, I would
> be happy to do that.

I think "consensus" was met with Jonathan's mail [1]. You must've read
it since you replied to it, or?

As I said in my first comment: put the changes into separate patches
(sorting the headers is one patch and the `guard(mutex)` another). Then
put all of them in *one* patch series. I hope this is clear enough...

[1] https://lore.kernel.org/lkml/20260309191504.616a9bd3@jic23-huawei/

On Thu, Mar 12, 2026 at 10:17 PM Waqar Hameed <waqar.hameed@axis.com> wrote:
>
> I think "consensus" was met with Jonathan's mail [1]. You must've read
> it since you replied to it, or?

Yes i have read that reply, i am sorry i misunderstood your statement i thought
it would be an update in styling rules or something then i will have to act.
Now i get it.

> As I said in my first comment: put the changes into separate patches
> (sorting the headers is one patch and the `guard(mutex)` another). Then
> put all of them in *one* patch series. I hope this is clear enough...

Yes it is clear, i will add separate patches in the series to put headers in
alphabetical order.

Thankyou,
Rajveer Chaudhari

On Thu, Mar 12, 2026 at 23:01 +0530 Rajveer Chaudhari <rajveer.chaudhari.linux@gmail.com> wrote:

> On Thu, Mar 12, 2026 at 10:17 PM Waqar Hameed <waqar.hameed@axis.com> wrote:
>>
>> I think "consensus" was met with Jonathan's mail [1]. You must've read
>> it since you replied to it, or?
>
> Yes i have read that reply, i am sorry i misunderstood your statement i thought
> it would be an update in styling rules or something then i will have to act.
> Now i get it.

[...]

No worries! As I said before, it's not always easy navigating the
different sub-systems in kernel development. A future tip is to see how
most other drivers are written, they usually tend to follow the guide
lines. If not, one can fix them on the go, just like here :)

On Fri, Mar 13, 2026 at 3:58 PM Waqar Hameed <waqar.hameed@axis.com> wrote:
>
> No worries! As I said before, it's not always easy navigating the
> different sub-systems in kernel development. A future tip is to see how
> most other drivers are written, they usually tend to follow the guide
> lines. If not, one can fix them on the go, just like here :)

Yesss got it!

Thank you :)