From: Gabriel Rondon <grondon@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
andy@kernel.org, "David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Stepan Ionichev" <sozdayvek@gmail.com>,
"Maxwell Doose" <m32285159@gmail.com>,
"Yash Suthar" <yashsuthar983@gmail.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/3] iio: accel: bmc150: use guard(mutex) for mutex handling
Date: Tue, 18 Aug 2026 16:41:35 +0100 [thread overview]
Message-ID: <20260818154135.3324-1-grondon@gmail.com> (raw)
In-Reply-To: <aoMrJvd4oSj0HgN4@ashevche-desk.local>
On Mon, Aug 17, 2026 at 06:39:18PM +0300, Andy Shevchenko wrote:
> Not directly related to this change, but even in the original code what is
> protected here by the mutex? data->scan.channels?
Agreed it is out of scope for this cleanup, so I left the scope unchanged.
Honest answer: not much that is obvious. data->scan.channels does not need
it, since the triggered handler is the only writer and the core serializes
it. The accel one-shot read is already gated with -EBUSY while buffering, so
bmc150_accel_get_axis cannot race the handler. What is left sharing
data->mutex and still reachable during capture is the temperature read, the
bandwidth get/set and scale set, and the event config. But since the handler
is a single regmap_bulk_read and regmap already serializes the bus, it is not
clear the driver mutex guards a real invariant here, and it may well be
vestigial.
Dropping it is a behavioral change worth its own patch and testing rather
than something to fold into a lock-syntax cleanup. Happy to look into that
separately.
Thanks,
Gabriel
next prev parent reply other threads:[~2026-08-18 15:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 23:42 [PATCH v4 0/3] iio: accel: bmc150: fix event-enable race, then use guard(mutex) Gabriel Rondon
2026-08-16 23:42 ` [PATCH v4 1/3] iio: accel: bmc150: sort header inclusions alphabetically Gabriel Rondon
2026-08-17 15:35 ` Andy Shevchenko
2026-08-16 23:42 ` [PATCH v4 2/3] iio: accel: bmc150: take the lock before checking ev_enable_state Gabriel Rondon
2026-08-16 23:42 ` [PATCH v4 3/3] iio: accel: bmc150: use guard(mutex) for mutex handling Gabriel Rondon
2026-08-17 15:39 ` Andy Shevchenko
2026-08-18 15:41 ` Gabriel Rondon [this message]
2026-08-18 15:47 ` Andy Shevchenko
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=20260818154135.3324-1-grondon@gmail.com \
--to=grondon@gmail.com \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m32285159@gmail.com \
--cc=nuno.sa@analog.com \
--cc=sozdayvek@gmail.com \
--cc=yashsuthar983@gmail.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.