Re: [PATCH v2 4/7] iio: core: Add cleanup.h support for iio_device_claim_*()

[Kurt Borja]

On Sat Dec 27, 2025 at 9:53 AM -05, Jonathan Cameron wrote:
> On Tue, 23 Dec 2025 11:23:24 -0600
> David Lechner <dlechner@xxxxxxxxxxxx> wrote:
>
>> On 12/11/25 8:45 PM, Kurt Borja wrote:
>> > Add guard classes for iio_device_claim_*() conditional locks. This will
>> > aid drivers write safer and cleaner code when dealing with some common
>> > patterns.
>> >   
>> 
>> 
>> > These classes are not meant to be used directly by drivers (hence the
>> > __priv__ prefix). Instead, documented wrapper macros are provided to
>> > enforce the use of ACQUIRE() or guard() semantics and avoid the
>> > problematic scoped guard.  
>> 
>> Would be useful to repeat this in a comment in the code.
>> 
> Given David did a much more thorough review than me I've just
> added a few comments on top.

Hi Jonathan,

...

>> > +/**
>> > + * IIO_DEV_ACQUIRE_BUFFER_MODE(_dev, _var) - Tries to acquire the buffer mode
>> > + *                                           lock with automatic release
>> > + * @_dev: IIO device instance
>> > + * @_var: Dummy variable identifier to store acquire result
>> > + *
>> > + * Tries to acquire the direct mode lock and automatically releases it at the
>> > + * end of the scope. It most be paired with IIO_DEV_ACQUIRE_ERR(), for example::
>> > + *
>> > + *	IIO_DEV_ACQUIRE_BUFFER_MODE(indio_dev, claim);
>> > + *	if (IIO_DEV_ACQUIRE_ERR(&claim))
>> > + *		return IRQ_HANDLED;
>> > + *
>> > + * Context: Can sleep
>> > + */
>> > +#define IIO_DEV_ACQUIRE_BUFFER_MODE(_dev, _var) \
>> > +	ACQUIRE(__priv__iio_dev_mode_lock_try_buffer, _var)(_dev)
>
> This one doesn't actually have any users I think?  Do we want to introduce
> it without them? I'm not sure we do.

I can drop it.

I would personally keep it for completeness, but you're right, the
buffer variant is very niche in general.

-- 
 ~ Kurt