[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77ca77847511e67066a150096a7af2fb84f1f25f.camel@gmail.com>
Date: Thu, 04 Dec 2025 14:36:30 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Kurt Borja <kuurtb@...il.com>, Andy Shevchenko
<andriy.shevchenko@...el.com>, Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>, Jonathan Cameron
<jic23@...nel.org>, 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>
Cc: David Lechner <dlechner@...libre.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 RFC 0/6] iio: core: Introduce cleanup.h support for mode
locks
On Wed, 2025-12-03 at 14:18 -0500, Kurt Borja 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}().
We already went this patch and then reverted it. I guess before we did not had
ACQUIRE() and ACQUIRE_ERR() but I'm not sure that makes it much better. Looking at the
last two patches on how we are handling the buffer mode stuff, I'm really not convinced...
Also, I have doubts sparse can keep up with the __cleanup stuff so I'm not sure the
annotations much make sense if we go down this path. Unless we want to use both
approaches which is also questionable.
- Nuno Sá
Powered by blists - more mailing lists