linux-kernel - Re: [PATCH v2 3/7] iio: core: Match 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] [day] [month] [year] [list]

Message-ID: <98897c0488e67f543f437b96412c78e10a59a81c.camel@gmail.com>
Date: Tue, 13 Jan 2026 10:38:44 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Jonathan Cameron <jic23@...nel.org>, Kurt Borja <kuurtb@...il.com>
Cc: 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>,
 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 v2 3/7] iio: core: Match iio_device_claim_*() semantics
 and implementation

On Sat, 2025-12-27 at 14:47 +0000, Jonathan Cameron wrote:
> On Thu, 11 Dec 2025 21:45:21 -0500
> Kurt Borja <kuurtb@...il.com> wrote:
> 
> > Implement iio_device_claim_buffer_mode() fully inline with the use of
> > __iio_dev_mode_lock(), which takes care of sparse annotations.
> > 
> > To completely match iio_device_claim_direct() semantics, we need to
> > also change iio_device_claim_buffer_mode() return semantics to usual
> > true/false conditional lock semantics.
> 
> I wasn't rushing to review this set because I want it to sit
> a little longer than a typical series to get more eyes on it.
> Anyhow, long enough for this version at least!
> 
> Whilst I find it hard to care strongly about out of tree drivers
> and in place flip of the return logic seems a bit unfair on anyone
> trying to keep those rebased on mainline!
> 
> So with that in mind, maybe we need to name it differently even
> if we are getting rid of the old implementation all in one patch.
> 
> Given earlier discussion about this one being rather more tricky
> to name than the claim_direct because claim_buffer sounds like
> we are grabbing the buffer, I'm not sure on the best naming to have
> here. iio_device_claim_buffer_m maybe?  Ugly though and
> these are super rare so maybe this isn't a particularly major
> concern.
> 
> Given I think the people maintaining most out of tree drivers
> are Analog Devices maybe this is a question Nuno can answer
> for us?
> 

Whatever you prefer :). I'll be the one taking care of any conflict
that comes and I do not mind dealing with something more painful if
the diff flow makes more sense for upstream.

Also not sure we have any out of tree user for these claim buffer APIs

- Nuno Sá