On Sun, Dec 17, 2023 at 11:36 AM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
> From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
>
> A lot of the advantages of the automated cleanup added for locks and similar
> are not that useful in IIO unless we also deal with the
> iio_device_claim_direct_mode() / iio_device_release_direct_mode()
> calls that prevent IIO device drivers from transitioning into buffered
> mode whilst calls are in flight + prevent sysfs reads and writes from
> interfering with buffered capture if it is enabled.
>
> Relies on Peter Zilstra's conditional cleanup handling which is queued
> up for the merge window in the tip tree. This series is based on
> a merge of tip/master into iio/togreg.
>
> All comments welcome. If this looks positive I'll make use of it in a
> lot more drivers, but hopefully these give an idea of how it will work.
>
> The need to always handle what happens after
> iio_device_claim_direct_scoped() {} is a little irritating but the
> compiler will warn if you don't do it and it's not obvious how to
> let the compiler know the magic loop (hidden in the cleanup.h macros)
> always runs once. Example:
>
> iio_device_claim_direct_scoped(return -EBUSY, indio_dev) {
> return 42;
> }
> /* Can't actually get here, but compiler moans if no return val */
> return -EINVAL;
Maybe better would be?
unreachable();
> }
