From: Peter Zijlstra <peterz@infradead.org>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: David Lechner <dlechner@baylibre.com>,
Jonathan Cameron <jic23@kernel.org>,
linux-iio@vger.kernel.org,
Cosmin Tanislav <demonsingur@gmail.com>,
Jagath Jog J <jagathjog1996@gmail.com>,
Gwendal Grignou <gwendal@chromium.org>,
Daniel Campello <campello@chromium.org>,
gregkh@linuxfoundation.org,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [RFC PATCH 1/8] iio: locking: introduce __cleanup() based direct mode claiming infrastructure
Date: Tue, 24 Oct 2023 17:28:00 +0200 [thread overview]
Message-ID: <20231024152800.GA13938@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231024151123.GB40044@noisy.programming.kicks-ass.net>
On Tue, Oct 24, 2023 at 05:11:23PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 23, 2023 at 10:55:56AM +0200, Nuno Sá wrote:
>
> > > > +/*
> > > > + * Auto cleanup version of iio_device_claim_direct_mode,
> > > > + *
> > > > + * CLASS(iio_claim_direct, claimed_dev)(indio_dev);
> > > > + * if (IS_ERR(claimed_dev))
> > > > + * return PTR_ERR(claimed_dev);
> > > > + *
> > > > + * st = iio_priv(claimed_dev);
> > > > + * ....
> > > > + */
> > > > +DEFINE_CLASS(iio_claim_direct, struct iio_dev *,
> > > > + iio_device_release_direct_mode(_T),
> > > > + ({
> > > > + struct iio_dev *dev;
> > > > + int d = iio_device_claim_direct_mode(_T);
> > > > +
> > > > + if (d < 0)
> > > > + dev = ERR_PTR(d);
> > > > + else
> > > > + dev = _T;
> > > > + dev;
> > > > + }),
> > > > + struct iio_dev *_T);
> > > > +
>
> > I don't really have a very strong opinion on this but what I really don't like
> > much is the pattern:
> >
> > CLASS(type, ret), where the return value is an argument of the macro... It would
> > be nice if we could just make it like:
> >
> > ret = guard(type)(...); //or any other variation of the guard() macro
> > if (ret)
> > return ret;
> >
> > the above could also be an error pointer or even have one variation of each. but
> > yeah, that likely means changing the cleanup.h file and that might be out of
> > scope for Jonathan's patch series.
>
> So I have a version for trylocks that I've not managed to send out.. it
> doesn't deal with arbitrary error codes, and as someone else down-thread
> noted, the guard() thing is not really suited for tricks like this.
>
> Notably I have a patch that converts ptrace_attach() to have a loop like:
>
> scoped_guard (mutex_intr, &task->signal->cred_guard_mutex) {
>
> goto success;
> }
> return -ERESTARTNOINTR;
>
> success:
> ...
> return 0;
>
>
> And another patch that does something like:
>
> scoped_cond_guard (rwsem_read_intr, no_lock,
> task ? &task->signal->exec_update_lock : NULL) {
>
> if (0) {
> no_lock:
> if (task)
> return -EINTR;
> }
>
> ...
> }
>
Hmm, looking at:
+ case IIO_CHAN_INFO_RAW: { /* magic value - channel value read */
+ CLASS(iio_claim_direct, claimed_dev)(indio_dev);
+ if (IS_ERR(claimed_dev))
+ return PTR_ERR(claimed_dev);
+ guard(mutex)(&st->lock);
+
switch (chan->type) {
case IIO_VOLTAGE:
if (chan->output) {
/* Set integer part to cached value */
*val = st->dac_val;
+ return IIO_VAL_INT;
} else if (chan->differential) {
if (chan->channel == 1)
*val = st->differential_adc_val[0];
else
*val = st->differential_adc_val[1];
+ return IIO_VAL_INT;
} else {
*val = st->single_ended_adc_val;
+ return IIO_VAL_INT;
}
+
case IIO_ACCEL:
*val = st->accel_val;
+ return IIO_VAL_INT;
default:
+ return -EINVAL;
}
+ }
And your iio_device_claim_direct_mode(), that is basically a trylock,
either it succeeds (and returns 0) or fails with -EBUSY.
Which means you could write your thing above like:
DEFINE_CLASS(iio_claim_direct, struct iio_dev *,
iio_device_release_direct_mode(_T),
({
struct iio_dev *dev;
int d = iio_device_claim_direct_mode(_T);
if (d < 0)
dev = NULL;
else
dev = _T;
dev;
}),
struct iio_dev *_T);
static inline void *
class_iio_claim_direct_lock_ptr(class_iio_claim_direct_t *_T)
{ return *_T; }
case IIO_CHAN_INFO_RAW: /* magic value - channel value read */
scoped_guard (iio_device_claim, indio_dev) {
guard(mutex)(&st->lock);
switch (chan->type) {
case ..:
return IIO_VAL_INT;
default:
return -EINVAL;
}
}
return -EBUSY;
and it would all just work, no?
next prev parent reply other threads:[~2023-10-24 15:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-22 15:47 [RFC PATCH 0/8] IIO: Use the new cleanup.h magic Jonathan Cameron
2023-10-22 15:47 ` [RFC PATCH 1/8] iio: locking: introduce __cleanup() based direct mode claiming infrastructure Jonathan Cameron
2023-10-22 21:10 ` David Lechner
2023-10-23 8:55 ` Nuno Sá
2023-10-23 9:53 ` Jonathan Cameron
2023-10-23 11:51 ` Nuno Sá
2023-10-23 14:34 ` Jonathan Cameron
2023-10-23 14:58 ` Nuno Sá
2023-10-24 12:23 ` Jonathan Cameron
2023-10-25 7:24 ` Nuno Sá
2023-10-24 15:11 ` Peter Zijlstra
2023-10-24 15:28 ` Peter Zijlstra [this message]
2023-10-28 16:59 ` Jonathan Cameron
2023-11-02 10:48 ` Peter Zijlstra
2023-11-03 15:19 ` Jonathan Cameron
2023-10-23 9:49 ` Jonathan Cameron
2023-10-22 15:47 ` [RFC PATCH 2/8] iio: dummy: Add use of new automated cleanup of locks and direct mode claiming Jonathan Cameron
2023-10-22 15:47 ` [RFC PATCH 3/8] iio: accel: adxl367: Use automated cleanup for locks and iio direct mode Jonathan Cameron
2023-10-22 15:47 ` [RFC PATCH 4/8] iio: imu: bmi323: Use cleanup handling for iio_device_claim_direct_mode() Jonathan Cameron
2023-10-22 15:47 ` [RFC PATCH 5/8] iio: adc: max1363: Use automatic cleanup for locks and iio mode claiming Jonathan Cameron
2023-10-22 15:47 ` [RFC PATCH 6/8] iio: proximity: sx9360: Use automated cleanup for locks and IIO " Jonathan Cameron
2023-10-22 15:47 ` [RFC PATCH 7/8] iio: proximity: sx9324: " Jonathan Cameron
2023-10-22 15:47 ` [RFC PATCH 8/8] iio: proximity: sx9310: " 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=20231024152800.GA13938@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=campello@chromium.org \
--cc=demonsingur@gmail.com \
--cc=dlechner@baylibre.com \
--cc=gregkh@linuxfoundation.org \
--cc=gwendal@chromium.org \
--cc=jagathjog1996@gmail.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=noname.nuno@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