All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Gabriel Rondon <grondon@gmail.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 18:47:56 +0300	[thread overview]
Message-ID: <aoR-rPWNMrqlFv2q@ashevche-desk.local> (raw)
In-Reply-To: <20260818154135.3324-1-grondon@gmail.com>

On Tue, Aug 18, 2026 at 04:41:35PM +0100, Gabriel Rondon wrote:
> 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.

Of course! Just made an observation.

> Happy to look into that separately.

If you have HW to test, I would like to see such a change.

-- 
With Best Regards,
Andy Shevchenko



      reply	other threads:[~2026-08-18 15:48 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
2026-08-18 15:47       ` Andy Shevchenko [this message]

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=aoR-rPWNMrqlFv2q@ashevche-desk.local \
    --to=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=grondon@gmail.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.