[RFC PATCH 0/8] IIO: Use the new cleanup.h magic

[Jonathan Cameron <jic23@kernel.org>]

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