On Sun, 17 Dec 2023 19:10:48 -0600
David Lechner <dlechner@xxxxxxxxxxxx> wrote:
> 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();
Interesting thought, but there is very little precedence for using that in the kernel.
+ I think it's a C23 feature so we'd be relying on whether gcc and clang happened
to implement it rather than being sure it was available.
Jonathan
>
> > }
