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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox