From: "Kurt Borja" <kuurtb@gmail.com>
To: "Jonathan Cameron" <jic23@kernel.org>, "Kurt Borja" <kuurtb@gmail.com>
Cc: "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>,
"David Lechner" <dlechner@baylibre.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 v5 0/7] iio: core: Introduce cleanup.h support for mode locks
Date: Thu, 22 Jan 2026 17:27:26 -0500 [thread overview]
Message-ID: <DFVH012QRDMJ.Y86WT9BEWQ3R@gmail.com> (raw)
In-Reply-To: <20260122191648.2c10cdf6@jic23-huawei>
On Thu Jan 22, 2026 at 2:16 PM -05, Jonathan Cameron wrote:
> On Tue, 20 Jan 2026 01:20:40 -0500
> Kurt Borja <kuurtb@gmail.com> wrote:
>
>> Hi,
>>
>> In a recent driver review discussion [1], Andy Shevchenko suggested we
>> add cleanup.h support for the lock API:
>>
>> iio_device_claim_{direct,buffer_mode}().
>>
>> Which would allow some nice code simplification in many places. Some
>> examples are given as patches, but the last two are the biggest
>> differences.
>>
>> In this version I dropped the RFC tag, as the general feeling is to go
>> through with this after some modifications. Main one is the addition of
>> IIO_DEV_ACQUIRE_{BUFFER,CLAIM}_MODE() wrappers to avoid drivers using
>> the guard classes directly. I also added comments on the forbidden ways
>> to use this API but I definitely still take suggestions on this.
>>
>> For now I dropped iio_device_claim_buffer_mode() rename, as this point
>> is still being discussed. My suggestion based on the RFC discussion is
>> to do it, but in a separate patch (using coccinelle) and while we're at
>> it rename the whole API like this:
>>
>> iio_dev_mode_lock()
>> iio_dev_mode_direct_trylock()
>> iio_dev_mode_buffer_trylock()
>> iio_dev_mode_unlock()
>>
>> Let me know what you think and thanks for taking a look!
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> I've queued this up. For now it'll just be pushed out on the testing branch.
> Hopefully the new noise from sparse won't bother anyone too much.
>
> Jonathan
Thank you for all the feedback!
I'll try to keep an eye on the lists in case of automatic reports.
--
Thanks,
~ Kurt
prev parent reply other threads:[~2026-01-22 22:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 6:20 [PATCH v5 0/7] iio: core: Introduce cleanup.h support for mode locks Kurt Borja
2026-01-20 6:20 ` [PATCH v5 1/7] iio: core: Add and export __iio_dev_mode_lock() Kurt Borja
2026-01-20 6:20 ` [PATCH v5 2/7] iio: core: Refactor iio_device_claim_direct() implementation Kurt Borja
2026-01-22 19:04 ` Jonathan Cameron
2026-01-22 22:20 ` Kurt Borja
2026-01-23 8:02 ` Andy Shevchenko
2026-01-23 8:01 ` Andy Shevchenko
2026-01-23 9:56 ` Jonathan Cameron
2026-01-20 6:20 ` [PATCH v5 3/7] iio: core: Match iio_device_claim_*() semantics and implementation Kurt Borja
2026-01-20 6:20 ` [PATCH v5 4/7] iio: core: Add cleanup.h support for iio_device_claim_*() Kurt Borja
2026-01-20 6:20 ` [PATCH v5 5/7] iio: light: vcnl4000: Use IIO cleanup helpers Kurt Borja
2026-01-22 19:12 ` Jonathan Cameron
2026-01-22 22:22 ` Kurt Borja
2026-01-20 6:20 ` [PATCH v5 6/7] iio: health: max30102: " Kurt Borja
2026-01-22 19:15 ` Jonathan Cameron
2026-01-20 6:20 ` [PATCH v5 7/7] iio: light: opt4060: " Kurt Borja
2026-01-22 19:16 ` [PATCH v5 0/7] iio: core: Introduce cleanup.h support for mode locks Jonathan Cameron
2026-01-22 22:27 ` Kurt Borja [this message]
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=DFVH012QRDMJ.Y86WT9BEWQ3R@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.