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

[Gabriel Rondon]

On Mon, 20 Apr 2026 19:15:19 +0100
Jonathan Cameron <jic23@xxxxxxxxxx> wrote:

> Not sure this list is useful in the commit log. Rather verbose.

Dropped the function list from the commit log in v2.

> I took a quick look and can't see anything beyond an if (ret) check
> in bmc150_accel_get_axis()
> If it's the only one left I'd use scoped_guard() for
> bmc150_accel_trigger_handler()

Agreed. v2 also converts bmc150_accel_get_axis() to guard(mutex), and
uses scoped_guard() for bmc150_accel_trigger_handler(), so no manual
mutex_lock()/mutex_unlock() pairs remain in the touched code.

> Unrelated change [int ret; movement] - here it just acts as noise
> [...] don't do this sort of code movement of lines we aren't
> otherwise touching.

Reverted; v2 leaves the declaration order in bmc150_accel_get_temp()
untouched.

> return sprintf(buf, "%d\n", data->watermark);
> [...] maybe also return sysfs_emit(...) is appropriate.

Done for bmc150_accel_get_fifo_watermark() and
bmc150_accel_get_fifo_state(); the intermediate variables are gone.
These already use sysfs_emit() in the current iio tree, so v2 keeps
sysfs_emit() and returns directly.

> Unrelated but [...] val = min(val, BMC150_ACCEL_FIFO_LENGTH);

Left out of v2 to keep this to a single logical change. Happy to send
it as a separate cleanup.

Thanks for the review.

Gabriel