Linux IIO development
 help / color / mirror / Atom feed
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?

  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