Re: [PATCH RFC 3/6] iio: core: Add cleanup.h support for iio_device_claim_*()

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 4 Dec 2025 19:36:28 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Thu, Dec 4, 2025 at 7:18 PM Kurt Borja <kuurtb@gmail.com> wrote:
> > On Wed Dec 3, 2025 at 5:34 PM -05, David Lechner wrote:  
> > > On 12/3/25 3:50 PM, David Lechner wrote:  
> > >> On 12/3/25 1:18 PM, Kurt Borja wrote:  
> 
> ...
> 
> > > When I made the comments about keeping "mode" in the name, I forgot
> > > that DEFINE_GUARD_COND() only extends a DEFINE_GUARD(). So I understand
> > > if we need to make names that fit a certain pattern rather than what
> > > I suggested.
> > >
> > > Still would be nice to have:
> > >
> > > iio_device_claim_mode()
> > > iio_device_claim_mode_direct()
> > > iio_device_claim_mode_buffer()
> > > iio_device_release_mode()
> > >
> > > Just really annoying to rename iio_device_{claim,release}_direct()
> > > everywhere since we just did that. We could keep both names around
> > > for a while though to avoid the churn.  

Definitely. Possibly indefinitely. I don't want a rename just to make
this facility easier to use as people won't see what is under the
ACQUIRE() anyway if we end up doing something like Rafael has done for
runtime PM where you don't call ACQUIRE() directly but use a runtime pm
specific macro (not sure if that will make this cycle or not, was
still being discussed when I went on holiday).

https://lore.kernel.org/all/3400866.aeNJFYEL58@rafael.j.wysocki/


> >
> > If we rename iio_device_claim_direct() (which is huge), maybe we can
> > pick shorter names and more descriptive names while at it? I was
> > thinking something like:
> >
> >         iio_mode_lock()
> >         iio_mode_lock_direct()
> >         iio_mode_lock_buffer()
> >         iio_mode_unlock()  
> 
> The device context is important, so at least iio_dev_mode_lock() (and so on).

If we are bringing lock into the name do we need to make it explicit which can fail?
Given you can't use them in the wrong place, maybe not.

iio_mode_lock_try_direct() or maybe iio_mode_lock_direct_try()?

This was less relevant when they all could fail.  Maybe we don't need to
bother given how rarely used the unconditional ones are.

I did like the claiming of mode terminology because it made it a little
more clear that we were taking a lock that was there for a purpose rather than
a normal lock.  Also the fact it's a lock is an implementation detail I'd
rather not back into the ABI.

Maybe it's worth something inspired by Rafael's patch linked above?

#define IIO_DEV_ACQUIRE_DIRECT_MODE(_dev, _var) \
	ACQUIRE(iio_device_claim_direct, _var)(_dev);
#define IIO_DEV_ACQUIRE_BUFFER_MODE(_dev, _var) \
	ACQUIRE(iio_device_claim_buffer, _var)(_dev);

For the two more complex ones and fine using guard() for the rare
any mode variant.

Then we can have whatever naming we like for the helpers under
the hood as no one will ever use them directly.

Hohum. Hardest problems in computer science etc, coherency and naming. :)


> 
> > Shorter names will also keep lines short when using guards.  
> 
>