linux-kernel - Re: [PATCH v2 4/7] iio: core: Add cleanup.h support for iio_device_claim

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DF977KU7WNXA.2B1WDUTKS7NRC@gmail.com>
Date: Sat, 27 Dec 2025 13:08:27 -0500
From: "Kurt Borja" <kuurtb@...il.com>
To: "Jonathan Cameron" <jic23@...nel.org>, "David Lechner"
 <dlechner@...libre.com>
Cc: "Kurt Borja" <kuurtb@...il.com>, "Andy Shevchenko"
 <andriy.shevchenko@...el.com>, "Lars-Peter Clausen" <lars@...afoo.de>,
 "Michael Hennerich" <Michael.Hennerich@...log.com>, "Benson Leung"
 <bleung@...omium.org>, "Antoniu Miclaus" <antoniu.miclaus@...log.com>,
 "Gwendal Grignou" <gwendal@...omium.org>, "Shrikant Raskar"
 <raskar.shree97@...il.com>, "Per-Daniel Olsson"
 <perdaniel.olsson@...s.com>, Nuno Sá <nuno.sa@...log.com>,
 "Andy Shevchenko" <andy@...nel.org>, "Guenter Roeck" <groeck@...omium.org>,
 "Jonathan Cameron" <Jonathan.Cameron@...wei.com>,
 <linux-iio@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <chrome-platform@...ts.linux.dev>
Subject: Re: [PATCH v2 4/7] iio: core: Add cleanup.h support for
 iio_device_claim_*()

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@...libre.com> 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