Linux IIO development
 help / color / mirror / Atom feed
* [RFC PATCH 0/8] IIO: Use the new cleanup.h magic
@ 2023-10-22 15:47 Jonathan Cameron
  2023-10-22 15:47 ` [RFC PATCH 1/8] iio: locking: introduce __cleanup() based direct mode claiming infrastructure Jonathan Cameron
                   ` (7 more replies)
  0 siblings, 8 replies; 23+ messages in thread
From: Jonathan Cameron @ 2023-10-22 15:47 UTC (permalink / raw)
  To: linux-iio
  Cc: Peter Zijlstra, Cosmin Tanislav, Jagath Jog J, Gwendal Grignou,
	Daniel Campello, gregkh, Jonathan Cameron

From: Jonathan Cameron <Jonathan.Cameron@huawei.com>

NB: I've only tested the example driver (dummy) changes - others are
build tested only so I'd like to see at least some testing on the
actual hardware.

Recently support was added to the kernel for automated cleanup based on
scope.  If the relevant variable goes out of scope, a destructor
function is called.

In most cases we are dealing with simple locking in which the guard() and
scoped_guard() magic can be used.

The one common more complex case is
iio_device_claim_direct_mode() / iio_device_release_direct_mode() which
takes a mutex only if we are not in buffered mode.
Typically this is used to avoid interfering with a devices configuration
when we are also streaming data into kernel buffers.  It's semantics
are that it will fail if we are in buffered mode (allow us to return
-EBUSY to userspace to indicate it should come back later) and otherwise
take the iio_dev->mlock and hold it until manually released.

Having looked at the various similar cases in Peter's patch set that
introduced this cleanup magic, I came up with the following:
(patch 1)
+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);
+

This returns a copy of the struct iio_dev pointer passed in if the lock
was taken, if not it returns ERR_PTR(-EBUSY).
iio_device_release_direct_mode() now safely handles ERR_PTR() and so
cleanup only unlocks the mutex if this succeeded.

It is used as

+ *	CLASS(iio_claim_direct, claimed_dev)(indio_dev);
+ *	if (IS_ERR(claimed_dev))
+ *		return PTR_ERR(claimed_dev);

when claimed_dev goes out of scope, iio_device_release_direct_mode() is
called.  I'm looking for review on whether this is correct / the simplest
approach.

This series is meant to introduce how this is used including adding it
to the dummy / example driver. I've converted a random set of drivers
over and if people are happy, many more would benefit from this treatment.
It's an RFC mostly to indicate to people that there may be dragons!

Jonathan Cameron (8):
  iio: locking: introduce __cleanup() based direct mode claiming
    infrastructure
  iio: dummy: Add use of new automated cleanup of locks and direct mode
    claiming.
  iio: accel: adxl367: Use automated cleanup for locks and iio direct
    mode.
  iio: imu: bmi323: Use cleanup handling for
    iio_device_claim_direct_mode()
  iio: adc: max1363: Use automatic cleanup for locks and iio mode
    claiming.
  iio: proximity: sx9360: Use automated cleanup for locks and IIO mode
    claiming.
  iio: proximity: sx9324: Use automated cleanup for locks and IIO mode
    claiming.
  iio: proximity: sx9310: Use automated cleanup for locks and IIO mode
    claiming.

 drivers/iio/accel/adxl367.c          | 214 ++++++++++-----------------
 drivers/iio/adc/max1363.c            |  63 ++++----
 drivers/iio/dummy/iio_simple_dummy.c | 145 +++++++++---------
 drivers/iio/imu/bmi323/bmi323_core.c |  61 ++++----
 drivers/iio/industrialio-core.c      |   4 +
 drivers/iio/proximity/sx9310.c       | 120 ++++++---------
 drivers/iio/proximity/sx9324.c       | 113 ++++++--------
 drivers/iio/proximity/sx9360.c       | 117 ++++++---------
 include/linux/iio/iio.h              |  25 ++++
 9 files changed, 368 insertions(+), 494 deletions(-)

-- 
2.42.0


^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2023-11-03 15:20 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox