mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: "Maxwell Doose" <m32285159@gmail.com>,
	"Tomasz Duszynski" <tduszyns@gmail.com>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"open list:IIO SUBSYSTEM AND DRIVERS" <linux-iio@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] iio: chemical: sps30: Replace manual locking with RAII locking
Date: Tue, 2 Jun 2026 12:49:40 +0100	[thread overview]
Message-ID: <20260602124940.6b7b75f4@jic23-huawei> (raw)
In-Reply-To: <ah6CfotGBX2VIAvL@ashevche-desk.local>

On Tue, 2 Jun 2026 10:13:02 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Tue, May 19, 2026 at 04:26:02PM -0500, Maxwell Doose wrote:
> > Replace manual mutex_lock() and mutex_unlock() calls with the much newer
> > guard(mutex)() and scoped_guard() macros to enable RAII patterns,
> > modernize the driver, and to increase readability.
> > 
> > Add guard(mutex)() into sps30_do_meas() as every caller locks it's call.  
> 
> ...
> 
> > -	mutex_lock(&state->lock);
> > +	guard(mutex)(&state->lock);
> > +
> >  	ret = state->ops->write_cleaning_period(state, cpu_to_be32(val));
> > -	if (ret) {
> > -		mutex_unlock(&state->lock);
> > +	if (ret)
> >  		return ret;
> > -	}
> >  
> >  	msleep(20);  
> 
> Hmm... msleep() under the mutex?
> 
Device needs to ensure no other access to the hardware whilst a reading
is ongoing.  Mutex being held over that sleep seems appropriate to me
given expectation is that any userspace code that is messing with other
paths that take the lock is shooting itself in the foot and should probably
be doing it's own serialization at a higher level (i.e. not hitting the
sysfs interface from mutliple threads).

Jonathan



      reply	other threads:[~2026-06-02 11:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19 21:26 Maxwell Doose
2026-05-20 12:22 ` Stepan Ionichev
2026-05-20 16:49   ` Maxwell Doose
2026-05-20 19:04     ` Jonathan Cameron
2026-05-20 20:07       ` Maxwell Doose
2026-06-02  7:13 ` Andy Shevchenko
2026-06-02 11:49   ` Jonathan Cameron [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=20260602124940.6b7b75f4@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m32285159@gmail.com \
    --cc=nuno.sa@analog.com \
    --cc=tduszyns@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®