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] [thread-next>] [day] [month] [year] [list]

Message-Id: <DF97CCMNGWVP.2JBZR7CQF1FID@gmail.com>
Date: Sat, 27 Dec 2025 13:14:41 -0500
From: "Kurt Borja" <kuurtb@...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 Dec 27, 2025 at 9:47 AM -05, 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.

You're right, I didn't really consider out-of-tree drivers.

>
> 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.

Yes, it's a bit ugly, but as I proposed in the cover letter, if we go
for a full API rename, it shouldn't matter for now?

What do you think about that?

I'll go for iio_device_claim_buffer_m() if I can't think of something
better.

>
> Given I think the people maintaining most out of tree drivers
> are Analog Devices maybe this is a question Nuno can answer
> for us?

-- 
 ~ Kurt