Re: [PATCH v2 3/7] iio: core: Match iio_device_claim_*() semantics and implementation

["Kurt Borja" <kuurtb@gmail.com>]

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