From: "Kurt Borja" <kuurtb@gmail.com>
To: "Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>
Cc: "Kurt Borja" <kuurtb@gmail.com>,
"Andy Shevchenko" <andriy.shevchenko@intel.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Benson Leung" <bleung@chromium.org>,
"Antoniu Miclaus" <antoniu.miclaus@analog.com>,
"Gwendal Grignou" <gwendal@chromium.org>,
"Shrikant Raskar" <raskar.shree97@gmail.com>,
"Per-Daniel Olsson" <perdaniel.olsson@axis.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Guenter Roeck" <groeck@chromium.org>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
chrome-platform@lists.linux.dev
Subject: Re: [PATCH v2 4/7] iio: core: Add cleanup.h support for iio_device_claim_*()
Date: Sat, 27 Dec 2025 13:08:27 -0500 [thread overview]
Message-ID: <DF977KU7WNXA.2B1WDUTKS7NRC@gmail.com> (raw)
In-Reply-To: <20251227145312.0f1c5f87@jic23-huawei>
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@baylibre.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
next prev parent reply other threads:[~2025-12-27 18:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 2:45 [PATCH v2 0/7] iio: core: Introduce cleanup.h support for mode locks Kurt Borja
2025-12-12 2:45 ` [PATCH v2 1/7] iio: core: Add and export __iio_dev_mode_lock() Kurt Borja
2025-12-12 18:21 ` Andy Shevchenko
2025-12-22 22:50 ` Kurt Borja
2025-12-23 17:19 ` David Lechner
2025-12-27 17:51 ` Kurt Borja
2025-12-27 18:13 ` David Lechner
2025-12-12 2:45 ` [PATCH v2 2/7] iio: core: Refactor iio_device_claim_direct() implementation Kurt Borja
2025-12-12 18:23 ` Andy Shevchenko
2025-12-23 17:20 ` David Lechner
2025-12-27 17:58 ` Kurt Borja
2025-12-12 2:45 ` [PATCH v2 3/7] iio: core: Match iio_device_claim_*() semantics and implementation Kurt Borja
2025-12-12 18:27 ` Andy Shevchenko
2025-12-27 14:47 ` Jonathan Cameron
2025-12-27 18:14 ` Kurt Borja
2025-12-27 18:24 ` David Lechner
2025-12-27 18:44 ` Kurt Borja
2025-12-12 2:45 ` [PATCH v2 4/7] iio: core: Add cleanup.h support for iio_device_claim_*() Kurt Borja
2025-12-23 17:23 ` David Lechner
2025-12-27 14:53 ` Jonathan Cameron
2025-12-27 18:08 ` Kurt Borja [this message]
2025-12-27 18:04 ` Kurt Borja
2025-12-27 18:20 ` David Lechner
2025-12-12 2:45 ` [PATCH v2 5/7] iio: light: vcnl4000: Use IIO cleanup helpers Kurt Borja
2025-12-12 2:45 ` [PATCH v2 6/7] iio: health: max30102: " Kurt Borja
2025-12-12 2:45 ` [PATCH v2 7/7] iio: light: opt4060: " Kurt Borja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DF977KU7WNXA.2B1WDUTKS7NRC@gmail.com \
--to=kuurtb@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Michael.Hennerich@analog.com \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=antoniu.miclaus@analog.com \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=dlechner@baylibre.com \
--cc=groeck@chromium.org \
--cc=gwendal@chromium.org \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=perdaniel.olsson@axis.com \
--cc=raskar.shree97@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).