From: Jonathan Cameron <jic23@kernel.org>
To: Neel Bullywon <neelb2403@gmail.com>
Cc: dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8] iio: magnetometer: bmc150_magn: use automated cleanup for mutex
Date: Sun, 1 Mar 2026 11:56:33 +0000 [thread overview]
Message-ID: <20260301115633.7529cbee@jic23-huawei> (raw)
In-Reply-To: <20260228172320.68144-1-neelb2403@gmail.com>
On Sat, 28 Feb 2026 12:23:20 -0500
Neel Bullywon <neelb2403@gmail.com> wrote:
> Use guard() and scoped_guard() to replace manual mutex lock/unlock
> calls. This simplifies error handling and ensures RAII-style cleanup.
>
> guard() is used in read_raw, write_raw, trig_reen, and
> trigger_set_state. Case blocks using guard() in read_raw and write_raw
> are wrapped in braces at the case label level to ensure clear scope for
> the cleanup guards.
>
> A bmc150_magn_set_power_mode_locked() helper is added to deduplicate
> the lock-call-unlock pattern used by remove, runtime_suspend, suspend,
> and resume.
>
> The trigger_handler function is left unchanged as mixing guard() with
> goto error paths can be fragile.
>
> Signed-off-by: Neel Bullywon <neelb2403@gmail.com>
Hi Neel
LGTM, but I'll leave some time for Andy to take another look if he
wants to.
One comment inline on a possible follow up bit of driver cleanup.
Jonathan
> ---
> I don't have BMC150 hardware, so I went with Andy's _locked() helper
> approach rather than moving the guard into bmc150_magn_set_power_mode()
> itself, which would touch the runtime PM locking Jonathan flagged as
> suspicious. The deeper runtime PM cleanup can be done separately by
> someone who can test it.
>
> v8:
> - Add bmc150_magn_set_power_mode_locked() helper to deduplicate the
> lock-call-unlock pattern in remove, runtime_suspend, suspend, and
> resume (Andy Shevchenko)
> v7:
> - Split into separate patches (Jonathan Cameron)
> v6:
> - Remove scoped_guard() from runtime_suspend and use guard() in
> suspend/resume (Jonathan Cameron)
> v5:
> - Use scoped_guard() instead of guard() in remove and
> runtime_suspend (Andy Shevchenko)
>
> drivers/iio/magnetometer/bmc150_magn.c | 112 ++++++++++---------------
> 1 file changed, 44 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/iio/magnetometer/bmc150_magn.c b/drivers/iio/magnetometer/bmc150_magn.c
> index 6a73f6e2f1f0..a4e2209f6ed4 100644
> --- a/drivers/iio/magnetometer/bmc150_magn.c
> +++ b/drivers/iio/magnetometer/bmc150_magn.c
> @@ -794,32 +788,28 @@ static int bmc150_magn_data_rdy_trigger_set_state(struct iio_trigger *trig,
> {
> struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
> struct bmc150_magn_data *data = iio_priv(indio_dev);
> - int ret = 0;
> + int ret;
> +
> + guard(mutex)(&data->mutex);
>
> - mutex_lock(&data->mutex);
> if (state == data->dready_trigger_on)
> - goto err_unlock;
> + return 0;
>
> ret = regmap_update_bits(data->regmap, BMC150_MAGN_REG_INT_DRDY,
> BMC150_MAGN_MASK_DRDY_EN,
> state << BMC150_MAGN_SHIFT_DRDY_EN);
A nice follow up might be to look for all cases like this in this driver
and make them
ret = regmap_assign_bits(data->regmap, BMC150_MAGN_REG_INT_DRDY,
BMC150_MAGN_MASK_DRDY_EN, state);
And drop that shift define.
> if (ret < 0)
> - goto err_unlock;
> + return ret;
>
> data->dready_trigger_on = state;
>
> if (state) {
> ret = bmc150_magn_reset_intr(data);
> if (ret < 0)
> - goto err_unlock;
> + return ret;
> }
> - mutex_unlock(&data->mutex);
>
> return 0;
> -
> -err_unlock:
> - mutex_unlock(&data->mutex);
> - return ret;
> }
next prev parent reply other threads:[~2026-03-01 11:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-28 17:23 [PATCH v8] iio: magnetometer: bmc150_magn: use automated cleanup for mutex Neel Bullywon
2026-03-01 11:56 ` Jonathan Cameron [this message]
2026-03-02 8:21 ` Andy Shevchenko
2026-03-02 21:15 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260301115633.7529cbee@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neelb2403@gmail.com \
--cc=nuno.sa@analog.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.