mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Kurt Borja <kuurtb@gmail.com>
Cc: "Andy Shevchenko" <andriy.shevchenko@intel.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Benson Leung" <bleung@chromium.org>,
	"Antoniu Miclaus" <antoniu.miclaus@analog.com>,
	"Gwendal Grignou" <gwendal@chromium.org>,
	"Shrikant Raskar" <raskar.shree97@gmail.com>,
	"Per-Daniel Olsson" <perdaniel.olsson@axis.com>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Guenter Roeck" <groeck@chromium.org>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	chrome-platform@lists.linux.dev
Subject: Re: [PATCH v2 3/7] iio: core: Match iio_device_claim_*() semantics and implementation
Date: Sat, 27 Dec 2025 14:47:07 +0000	[thread overview]
Message-ID: <20251227144707.1bebcf27@jic23-huawei> (raw)
In-Reply-To: <20251211-lock-impr-v2-3-6fb47bdaaf24@gmail.com>

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.

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?


> 
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>



  parent reply	other threads:[~2025-12-27 14:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12  2:45 [PATCH v2 0/7] iio: core: Introduce cleanup.h support for mode locks Kurt Borja
2025-12-12  2:45 ` [PATCH v2 1/7] iio: core: Add and export __iio_dev_mode_lock() Kurt Borja
2025-12-12 18:21   ` Andy Shevchenko
2025-12-22 22:50     ` Kurt Borja
2025-12-23 17:19   ` David Lechner
2025-12-27 17:51     ` Kurt Borja
2025-12-27 18:13       ` David Lechner
2025-12-12  2:45 ` [PATCH v2 2/7] iio: core: Refactor iio_device_claim_direct() implementation Kurt Borja
2025-12-12 18:23   ` Andy Shevchenko
2025-12-23 17:20   ` David Lechner
2025-12-27 17:58     ` Kurt Borja
2025-12-12  2:45 ` [PATCH v2 3/7] iio: core: Match iio_device_claim_*() semantics and implementation Kurt Borja
2025-12-12 18:27   ` Andy Shevchenko
2025-12-27 14:47   ` Jonathan Cameron [this message]
2025-12-27 18:14     ` Kurt Borja
2025-12-27 18:24       ` David Lechner
2025-12-27 18:44         ` Kurt Borja
2026-01-11 11:33           ` Jonathan Cameron
2026-01-13 10:38     ` Nuno Sá
2025-12-12  2:45 ` [PATCH v2 4/7] iio: core: Add cleanup.h support for iio_device_claim_*() Kurt Borja
2025-12-23 17:23   ` David Lechner
2025-12-27 14:53     ` Jonathan Cameron
2025-12-27 18:08       ` Kurt Borja
2025-12-27 18:04     ` Kurt Borja
2025-12-27 18:20       ` David Lechner
2025-12-12  2:45 ` [PATCH v2 5/7] iio: light: vcnl4000: Use IIO cleanup helpers Kurt Borja
2025-12-12  2:45 ` [PATCH v2 6/7] iio: health: max30102: " Kurt Borja
2025-12-12  2:45 ` [PATCH v2 7/7] iio: light: opt4060: " Kurt Borja

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251227144707.1bebcf27@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=antoniu.miclaus@analog.com \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=dlechner@baylibre.com \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=kuurtb@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=perdaniel.olsson@axis.com \
    --cc=raskar.shree97@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®