linux-kernel - Re: [PATCH v3 0/7] iio: core: Introduce cleanup.h support for mode locks

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4e77ebef-07b3-49ae-9d53-d24616569a74@baylibre.com>
Date: Fri, 16 Jan 2026 16:08:07 -0600
From: David Lechner <dlechner@...libre.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: 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 v3 0/7] iio: core: Introduce cleanup.h support for mode
 locks

On 1/6/26 2:06 AM, 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}().
> 
> 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@...il.com>
> ---
Like Jonathan, I just had a few minor suggestions, but overall:

Reviewed-by: David Lechner <dlechner@...libre.com>