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

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

[Kurt Borja]

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@gmail.com>
---
v3:

  - Reword commit message of patch 1: infallible -> unconditional.

  - Drop "*strongly*" in __iio_dev_mode_lock() kernel-doc and be a bit
    more clear on the function's intention.

  - Keep comment about inline functions and sparse markings, but drop
    the __cond_acquires() part, as the new implementation makes it
    unnecessary.

  - Implement iio_device_release_*() as macros around
    __iio_dev_mode_unlock().

  - Rename iio_device_claim_buffer_mode() ->
    iio_device_try_claim_buffer_mode() to avoid silently breaking
    out-of-tree drivers.

  - Drop the `_` argument prefix in new macros, as there are no name
    conflicts.

  - Drop "dummy" from IIO_DEV_ACQUIRE_DIRECT_MODE kernel-doc, as the
    `claim` variable does store the error value.

  - Drop IIO_DEV_ACQUIRE_BUFFER_MODE() until a driver actually needs it.

  - Rename IIO_DEV_ACQUIRE_ERR() -> IIO_DEV_ACQUIRE_FAILED() to make the
    name more clear.

  - Rename IIO_DEV_GUARD_ANY_MODE() -> IIO_DEV_GUARD_CURRENT_MODE() to
    make the name more clear.

  - Add missing . in iio_device_release_direct() kernel-doc.

  NOTE: Andy suggested __iio_dev_mode_*() be exported into the IIO_CORE
        namespace. However, this cannot be done because these functions
	need to be called inline, so Sparse can see the __acquires() and
	__releases() tags.

  Happy new year to everyone :)

v2: https://lore.kernel.org/r/20251211-lock-impr-v2-0-6fb47bdaaf24@gmail.com

  - Add __iio_dev_mode_lock() (formerly iio_device_claim()) in the first
    patch.

  - Added comments to make sure __iio_dev_mode_lock() is not used by
    drivers to protect internal state, or in general.

  - Add patch which re-implements iio_device_claim_direct() using
    __iio_dev_mode_lock().

  - Match iio_device_claim_buffer_mode() semantics by reimplementing it
    in the same way as iio_device_claim_direct().

  - Guard classes now are prefixed with __priv__ to make sure drivers
    don't use them directly.

  - Add IIO_DEV_ACQUIRE_{BUFFER,DIRECT}_MODE() documented wrappers

  - Avoid any function renames (for now).

  - Rename dummy variable `claim` instead of `busy` on vcnl4000 patch.

  - Avoid scoped guard in max30102.

  - Keep using iio_trigger_validate_own_device() insted of
    iio_trigger_using_own() in opt4060.

v1: https://lore.kernel.org/r/20251203-lock-impr-v1-0-b4a1fd639423@gmail.com

---
Kurt Borja (7):
      iio: core: Add and export __iio_dev_mode_lock()
      iio: core: Refactor iio_device_claim_direct() implementation
      iio: core: Match iio_device_claim_*() semantics and implementation
      iio: core: Add cleanup.h support for iio_device_claim_*()
      iio: light: vcnl4000: Use IIO cleanup helpers
      iio: health: max30102: Use IIO cleanup helpers
      iio: light: opt4060: Use IIO cleanup helpers

 drivers/iio/adc/ade9000.c                          |   2 +-
 .../common/cros_ec_sensors/cros_ec_sensors_core.c  |   5 +-
 drivers/iio/health/max30100.c                      |   8 +-
 drivers/iio/health/max30102.c                      |  33 ++---
 drivers/iio/industrialio-core.c                    |  86 +++---------
 drivers/iio/light/opt4060.c                        |  52 +++-----
 drivers/iio/light/vcnl4000.c                       |  49 +++----
 include/linux/iio/iio.h                            | 145 +++++++++++++++++++--
 8 files changed, 196 insertions(+), 184 deletions(-)
---
base-commit: fb2f4eb29a258145b0336601f00509cab6e93e7c
change-id: 20251130-lock-impr-6f22748c15e8

-- 
 ~ Kurt

[PATCH v3 1/7] iio: core: Add and export __iio_dev_mode_lock()

[Kurt Borja]

Add unconditional wrappers around the internal IIO mode lock.

As mentioned in the documentation, this is not meant to be used by
drivers, instead this will aid in the eventual addition of cleanup
classes around conditional locks.

Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
 drivers/iio/industrialio-core.c | 30 ++++++++++++++++++++++++++++++
 include/linux/iio/iio.h         |  3 +++
 2 files changed, 33 insertions(+)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index f69deefcfb6f..34867a860a84 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -2171,6 +2171,36 @@ int __devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev,
 }
 EXPORT_SYMBOL_GPL(__devm_iio_device_register);
 
+/**
+ * __iio_dev_mode_lock - Locks the current IIO device mode
+ * @indio_dev: the iio_dev associated with the device
+ *
+ * If the device is either in direct or buffer mode, it's guaranteed to stay
+ * that way until __iio_dev_mode_unlock() is called.
+ *
+ * This function is not meant to be used directly by drivers to protect internal
+ * state, a driver should have it's own mechanisms for that matter.
+ *
+ * There are very few cases where a driver actually needs to lock the current
+ * mode unconditionally. It's recommended to use iio_device_claim_direct() or
+ * iio_device_claim_buffer_mode() pairs or related helpers instead.
+ */
+void __iio_dev_mode_lock(struct iio_dev *indio_dev)
+{
+	mutex_lock(&to_iio_dev_opaque(indio_dev)->mlock);
+}
+EXPORT_SYMBOL_GPL(__iio_dev_mode_lock);
+
+/**
+ * __iio_dev_mode_unlock - Unlocks the current IIO device mode
+ * @indio_dev: the iio_dev associated with the device
+ */
+void __iio_dev_mode_unlock(struct iio_dev *indio_dev)
+{
+	mutex_unlock(&to_iio_dev_opaque(indio_dev)->mlock);
+}
+EXPORT_SYMBOL_GPL(__iio_dev_mode_unlock);
+
 /**
  * __iio_device_claim_direct - Keep device in direct mode
  * @indio_dev:	the iio_dev associated with the device
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 872ebdf0dd77..aecda887d833 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -661,6 +661,9 @@ void iio_device_unregister(struct iio_dev *indio_dev);
 int __devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev,
 			       struct module *this_mod);
 int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp);
+
+void __iio_dev_mode_lock(struct iio_dev *indio_dev) __acquires(indio_dev);
+void __iio_dev_mode_unlock(struct iio_dev *indio_dev) __releases(indio_dev);
 bool __iio_device_claim_direct(struct iio_dev *indio_dev);
 void __iio_device_release_direct(struct iio_dev *indio_dev);
 

-- 
2.52.0

Re: [PATCH v3 1/7] iio: core: Add and export __iio_dev_mode_lock()

[Jonathan Cameron]

On Tue, 06 Jan 2026 03:06:56 -0500
Kurt Borja <kuurtb@gmail.com> wrote:

> Add unconditional wrappers around the internal IIO mode lock.
> 
> As mentioned in the documentation, this is not meant to be used by
> drivers, instead this will aid in the eventual addition of cleanup
> classes around conditional locks.
> 
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
Hi Kurt,

I'm being a bit conservative in looking to apply this so apologies
if it seems like I'm ignoring you! I wanted to give plenty of time
for others to take a look.

A few comments, but if we go with this version I'll tweak the
punctuation if I remember whilst applying.

Jonathan


> ---
>  drivers/iio/industrialio-core.c | 30 ++++++++++++++++++++++++++++++
>  include/linux/iio/iio.h         |  3 +++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index f69deefcfb6f..34867a860a84 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -2171,6 +2171,36 @@ int __devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev,
>  }
>  EXPORT_SYMBOL_GPL(__devm_iio_device_register);
>  
> +/**
> + * __iio_dev_mode_lock - Locks the current IIO device mode
> + * @indio_dev: the iio_dev associated with the device
> + *
> + * If the device is either in direct or buffer mode, it's guaranteed to stay
> + * that way until __iio_dev_mode_unlock() is called.
> + *
> + * This function is not meant to be used directly by drivers to protect internal
> + * state, a driver should have it's own mechanisms for that matter.

Nitpick, shouldn't be a comma.  Either

 * This function is not meant to be used directly by drivers to protect internal
 * state. A driver should have it's own mechanisms for that matter.

or if you like fancy uses of the semi colon.

 * This function is not meant to be used directly by drivers to protect internal
 * state; a driver should have it's own mechanisms for that matter.

> + *
> + * There are very few cases where a driver actually needs to lock the current
> + * mode unconditionally. It's recommended to use iio_device_claim_direct() or
> + * iio_device_claim_buffer_mode() pairs or related helpers instead.
> + */
> +void __iio_dev_mode_lock(struct iio_dev *indio_dev)
> +{
> +	mutex_lock(&to_iio_dev_opaque(indio_dev)->mlock);
> +}
> +EXPORT_SYMBOL_GPL(__iio_dev_mode_lock);
> +
> +/**
> + * __iio_dev_mode_unlock - Unlocks the current IIO device mode
> + * @indio_dev: the iio_dev associated with the device
> + */
> +void __iio_dev_mode_unlock(struct iio_dev *indio_dev)
> +{
> +	mutex_unlock(&to_iio_dev_opaque(indio_dev)->mlock);
> +}
> +EXPORT_SYMBOL_GPL(__iio_dev_mode_unlock);
> +
>  /**
>   * __iio_device_claim_direct - Keep device in direct mode
>   * @indio_dev:	the iio_dev associated with the device
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index 872ebdf0dd77..aecda887d833 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -661,6 +661,9 @@ void iio_device_unregister(struct iio_dev *indio_dev);
>  int __devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev,
>  			       struct module *this_mod);
>  int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp);
> +
> +void __iio_dev_mode_lock(struct iio_dev *indio_dev) __acquires(indio_dev);
> +void __iio_dev_mode_unlock(struct iio_dev *indio_dev) __releases(indio_dev);
This is an interesting notation choice as there are several locks embedded
in iio_devs but I think it is the only one we want to expose so fair enough
if we don't see any false warnings from this!

Jonathan

>  bool __iio_device_claim_direct(struct iio_dev *indio_dev);
>  void __iio_device_release_direct(struct iio_dev *indio_dev);
>  
> 

Re: [PATCH v3 1/7] iio: core: Add and export __iio_dev_mode_lock()

[Kurt Borja]

On Fri Jan 16, 2026 at 3:18 PM -05, Jonathan Cameron wrote:
> On Tue, 06 Jan 2026 03:06:56 -0500
> Kurt Borja <kuurtb@gmail.com> wrote:
>
>> Add unconditional wrappers around the internal IIO mode lock.
>> 
>> As mentioned in the documentation, this is not meant to be used by
>> drivers, instead this will aid in the eventual addition of cleanup
>> classes around conditional locks.
>> 
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> Hi Kurt,
>
> I'm being a bit conservative in looking to apply this so apologies
> if it seems like I'm ignoring you! I wanted to give plenty of time
> for others to take a look.

Hi Jonathan,

Oh -- don't worry. It's understandable for API changes. Thanks for
clarifying!

>
> A few comments, but if we go with this version I'll tweak the
> punctuation if I remember whilst applying.

I will fix the ones you mentioned here. Apologies if there is more.

...

>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>> index 872ebdf0dd77..aecda887d833 100644
>> --- a/include/linux/iio/iio.h
>> +++ b/include/linux/iio/iio.h
>> @@ -661,6 +661,9 @@ void iio_device_unregister(struct iio_dev *indio_dev);
>>  int __devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev,
>>  			       struct module *this_mod);
>>  int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp);
>> +
>> +void __iio_dev_mode_lock(struct iio_dev *indio_dev) __acquires(indio_dev);
>> +void __iio_dev_mode_unlock(struct iio_dev *indio_dev) __releases(indio_dev);
> This is an interesting notation choice as there are several locks embedded
> in iio_devs but I think it is the only one we want to expose so fair enough
> if we don't see any false warnings from this!

The previous implementation also used __acquire(indio_dev) and I do
believe is the best choice, for the reasons you mentioned. Also the
mlock is inside iio_dev_opaque and we don't have access to that in
iio.h.

>
> Jonathan
>
>>  bool __iio_device_claim_direct(struct iio_dev *indio_dev);
>>  void __iio_device_release_direct(struct iio_dev *indio_dev);
>>  
>> 


-- 
Thanks,
 ~ Kurt

[PATCH v3 2/7] iio: core: Refactor iio_device_claim_direct() implementation

[Kurt Borja]

In order to eventually unify the locking API, implement
iio_device_claim_direct() fully inline, with the use of
__iio_dev_mode_lock(), which takes care of sparse annotations.

Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
 drivers/iio/industrialio-core.c | 44 -----------------------------------------
 include/linux/iio/iio.h         | 40 ++++++++++++++++++++++++++-----------
 2 files changed, 28 insertions(+), 56 deletions(-)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 34867a860a84..550d100d9cfa 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -2201,50 +2201,6 @@ void __iio_dev_mode_unlock(struct iio_dev *indio_dev)
 }
 EXPORT_SYMBOL_GPL(__iio_dev_mode_unlock);
 
-/**
- * __iio_device_claim_direct - Keep device in direct mode
- * @indio_dev:	the iio_dev associated with the device
- *
- * If the device is in direct mode it is guaranteed to stay
- * that way until __iio_device_release_direct() is called.
- *
- * Use with __iio_device_release_direct().
- *
- * Drivers should only call iio_device_claim_direct().
- *
- * Returns: true on success, false on failure.
- */
-bool __iio_device_claim_direct(struct iio_dev *indio_dev)
-{
-	struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
-
-	mutex_lock(&iio_dev_opaque->mlock);
-
-	if (iio_buffer_enabled(indio_dev)) {
-		mutex_unlock(&iio_dev_opaque->mlock);
-		return false;
-	}
-	return true;
-}
-EXPORT_SYMBOL_GPL(__iio_device_claim_direct);
-
-/**
- * __iio_device_release_direct - releases claim on direct mode
- * @indio_dev:	the iio_dev associated with the device
- *
- * Release the claim. Device is no longer guaranteed to stay
- * in direct mode.
- *
- * Drivers should only call iio_device_release_direct().
- *
- * Use with __iio_device_claim_direct()
- */
-void __iio_device_release_direct(struct iio_dev *indio_dev)
-{
-	mutex_unlock(&to_iio_dev_opaque(indio_dev)->mlock);
-}
-EXPORT_SYMBOL_GPL(__iio_device_release_direct);
-
 /**
  * iio_device_claim_buffer_mode - Keep device in buffer mode
  * @indio_dev:	the iio_dev associated with the device
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index aecda887d833..3cf340208694 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -664,31 +664,47 @@ int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp);
 
 void __iio_dev_mode_lock(struct iio_dev *indio_dev) __acquires(indio_dev);
 void __iio_dev_mode_unlock(struct iio_dev *indio_dev) __releases(indio_dev);
-bool __iio_device_claim_direct(struct iio_dev *indio_dev);
-void __iio_device_release_direct(struct iio_dev *indio_dev);
 
 /*
  * Helper functions that allow claim and release of direct mode
  * in a fashion that doesn't generate many false positives from sparse.
  * Note this must remain static inline in the header so that sparse
- * can see the __acquire() marking. Revisit when sparse supports
- * __cond_acquires()
+ * can see the __acquires() and __releases() markings.
+ */
+
+/**
+ * iio_device_claim_direct - Keep device in direct mode
+ * @indio_dev:	the iio_dev associated with the device
+ *
+ * If the device is in direct mode it is guaranteed to stay
+ * that way until iio_device_release_direct() is called.
+ *
+ * Use with iio_device_release_direct().
+ *
+ * Returns: true on success, false on failure.
  */
 static inline bool iio_device_claim_direct(struct iio_dev *indio_dev)
 {
-	if (!__iio_device_claim_direct(indio_dev))
-		return false;
+	__iio_dev_mode_lock(indio_dev);
 
-	__acquire(iio_dev);
+	if (iio_buffer_enabled(indio_dev)) {
+		__iio_dev_mode_unlock(indio_dev);
+		return false;
+	}
 
 	return true;
 }
 
-static inline void iio_device_release_direct(struct iio_dev *indio_dev)
-{
-	__iio_device_release_direct(indio_dev);
-	__release(indio_dev);
-}
+/**
+ * iio_device_release_direct - Releases claim on direct mode
+ * @indio_dev:	the iio_dev associated with the device
+ *
+ * Release the claim. Device is no longer guaranteed to stay
+ * in direct mode.
+ *
+ * Use with iio_device_claim_direct().
+ */
+#define iio_device_release_direct(indio_dev) __iio_dev_mode_unlock(indio_dev)
 
 int iio_device_claim_buffer_mode(struct iio_dev *indio_dev);
 void iio_device_release_buffer_mode(struct iio_dev *indio_dev);

-- 
2.52.0

Re: [PATCH v3 2/7] iio: core: Refactor iio_device_claim_direct() implementation

[David Lechner]

On 1/6/26 2:06 AM, Kurt Borja wrote:
> In order to eventually unify the locking API, implement
> iio_device_claim_direct() fully inline, with the use of
> __iio_dev_mode_lock(), which takes care of sparse annotations.
> 
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---

...

> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index aecda887d833..3cf340208694 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -664,31 +664,47 @@ int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp);
>  
>  void __iio_dev_mode_lock(struct iio_dev *indio_dev) __acquires(indio_dev);
>  void __iio_dev_mode_unlock(struct iio_dev *indio_dev) __releases(indio_dev);
> -bool __iio_device_claim_direct(struct iio_dev *indio_dev);
> -void __iio_device_release_direct(struct iio_dev *indio_dev);
>  
>  /*
>   * Helper functions that allow claim and release of direct mode
>   * in a fashion that doesn't generate many false positives from sparse.
>   * Note this must remain static inline in the header so that sparse
> - * can see the __acquire() marking. Revisit when sparse supports
> - * __cond_acquires()
> + * can see the __acquires() and __releases() markings.
> + */
> +
nit: I think "attributes" would be more technically correct than
"markings" (since we are touching this).

Re: [PATCH v3 2/7] iio: core: Refactor iio_device_claim_direct() implementation

[Kurt Borja]

On Sat Jan 17, 2026 at 7:01 AM -05, Andy Shevchenko wrote:
> пʼятниця, 16 січня 2026 р. David Lechner <dlechner@baylibre.com> пише:
>
>> On 1/6/26 2:06 AM, Kurt Borja wrote:
>> > In order to eventually unify the locking API, implement
>> > iio_device_claim_direct() fully inline, with the use of
>> > __iio_dev_mode_lock(), which takes care of sparse annotations.
>> >
>> > Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> > ---
>>
>> ...
>>
>> > diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>> > index aecda887d833..3cf340208694 100644
>> > --- a/include/linux/iio/iio.h
>> > +++ b/include/linux/iio/iio.h
>> > @@ -664,31 +664,47 @@ int iio_push_event(struct iio_dev *indio_dev, u64
>> ev_code, s64 timestamp);
>> >
>> >  void __iio_dev_mode_lock(struct iio_dev *indio_dev)
>> __acquires(indio_dev);
>> >  void __iio_dev_mode_unlock(struct iio_dev *indio_dev)
>> __releases(indio_dev);
>> > -bool __iio_device_claim_direct(struct iio_dev *indio_dev);
>> > -void __iio_device_release_direct(struct iio_dev *indio_dev);
>> >
>> >  /*
>> >   * Helper functions that allow claim and release of direct mode
>> >   * in a fashion that doesn't generate many false positives from sparse.
>> >   * Note this must remain static inline in the header so that sparse
>> > - * can see the __acquire() marking. Revisit when sparse supports
>> > - * __cond_acquires()
>> > + * can see the __acquires() and __releases() markings.
>> > + */
>> > +
>> nit: I think "attributes" would be more technically correct than
>> "markings" (since we are touching this).
>>
>
> The annotations is slightly better because these are for sparse and not for
> compiler.

Hi Andy,

Yes, annotations also matches the Sparse documentation so I'll go with
that.


-- 
Thanks,
 ~ Kurt

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

[Kurt Borja]

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.

Additionally, to avoid silently breaking out-of-tree drivers, rename
iio_device_claim_buffer_mode() to iio_device_claim_try_buffer_mode().

Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
 drivers/iio/adc/ade9000.c                          |  2 +-
 .../common/cros_ec_sensors/cros_ec_sensors_core.c  |  5 +--
 drivers/iio/health/max30100.c                      |  8 +----
 drivers/iio/health/max30102.c                      |  2 +-
 drivers/iio/industrialio-core.c                    | 42 +---------------------
 drivers/iio/light/opt4060.c                        |  2 +-
 include/linux/iio/iio.h                            | 35 ++++++++++++++++--
 7 files changed, 39 insertions(+), 57 deletions(-)

diff --git a/drivers/iio/adc/ade9000.c b/drivers/iio/adc/ade9000.c
index 2de8a718d62a..db085dc5e526 100644
--- a/drivers/iio/adc/ade9000.c
+++ b/drivers/iio/adc/ade9000.c
@@ -964,7 +964,7 @@ static irqreturn_t ade9000_dready_thread(int irq, void *data)
 	struct iio_dev *indio_dev = data;
 
 	/* Handle data ready interrupt from C4/EVENT/DREADY pin */
-	if (!iio_device_claim_buffer_mode(indio_dev)) {
+	if (iio_device_try_claim_buffer_mode(indio_dev)) {
 		ade9000_iio_push_buffer(indio_dev);
 		iio_device_release_buffer_mode(indio_dev);
 	}
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index 9ac80e4b7d75..ef53066b1735 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -188,11 +188,8 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev,
 	/*
 	 * Ignore samples if the buffer is not set: it is needed if the ODR is
 	 * set but the buffer is not enabled yet.
-	 *
-	 * Note: iio_device_claim_buffer_mode() returns -EBUSY if the buffer
-	 * is not enabled.
 	 */
-	if (iio_device_claim_buffer_mode(indio_dev) < 0)
+	if (!iio_device_try_claim_buffer_mode(indio_dev))
 		return 0;
 
 	out = (s16 *)st->samples;
diff --git a/drivers/iio/health/max30100.c b/drivers/iio/health/max30100.c
index 3d441013893c..7dfdb5eb305e 100644
--- a/drivers/iio/health/max30100.c
+++ b/drivers/iio/health/max30100.c
@@ -417,13 +417,7 @@ static int max30100_read_raw(struct iio_dev *indio_dev,
 		 * Temperature reading can only be acquired while engine
 		 * is running
 		 */
-		if (iio_device_claim_buffer_mode(indio_dev)) {
-			/*
-			 * Replacing -EBUSY or other error code
-			 * returned by iio_device_claim_buffer_mode()
-			 * because user space may rely on the current
-			 * one.
-			 */
+		if (!iio_device_try_claim_buffer_mode(indio_dev)) {
 			ret = -EAGAIN;
 		} else {
 			ret = max30100_get_temp(data, val);
diff --git a/drivers/iio/health/max30102.c b/drivers/iio/health/max30102.c
index a48c0881a4c7..6918fcb5de2b 100644
--- a/drivers/iio/health/max30102.c
+++ b/drivers/iio/health/max30102.c
@@ -476,7 +476,7 @@ static int max30102_read_raw(struct iio_dev *indio_dev,
 		 * shutdown; leave shutdown briefly when buffer not running
 		 */
 any_mode_retry:
-		if (iio_device_claim_buffer_mode(indio_dev)) {
+		if (!iio_device_try_claim_buffer_mode(indio_dev)) {
 			/*
 			 * This one is a *bit* hacky. If we cannot claim buffer
 			 * mode, then try direct mode so that we make sure
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 550d100d9cfa..52a16ce87e02 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -2183,7 +2183,7 @@ EXPORT_SYMBOL_GPL(__devm_iio_device_register);
  *
  * There are very few cases where a driver actually needs to lock the current
  * mode unconditionally. It's recommended to use iio_device_claim_direct() or
- * iio_device_claim_buffer_mode() pairs or related helpers instead.
+ * iio_device_try_claim_buffer_mode() pairs or related helpers instead.
  */
 void __iio_dev_mode_lock(struct iio_dev *indio_dev)
 {
@@ -2201,46 +2201,6 @@ void __iio_dev_mode_unlock(struct iio_dev *indio_dev)
 }
 EXPORT_SYMBOL_GPL(__iio_dev_mode_unlock);
 
-/**
- * iio_device_claim_buffer_mode - Keep device in buffer mode
- * @indio_dev:	the iio_dev associated with the device
- *
- * If the device is in buffer mode it is guaranteed to stay
- * that way until iio_device_release_buffer_mode() is called.
- *
- * Use with iio_device_release_buffer_mode().
- *
- * Returns: 0 on success, -EBUSY on failure.
- */
-int iio_device_claim_buffer_mode(struct iio_dev *indio_dev)
-{
-	struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
-
-	mutex_lock(&iio_dev_opaque->mlock);
-
-	if (iio_buffer_enabled(indio_dev))
-		return 0;
-
-	mutex_unlock(&iio_dev_opaque->mlock);
-	return -EBUSY;
-}
-EXPORT_SYMBOL_GPL(iio_device_claim_buffer_mode);
-
-/**
- * iio_device_release_buffer_mode - releases claim on buffer mode
- * @indio_dev:	the iio_dev associated with the device
- *
- * Release the claim. Device is no longer guaranteed to stay
- * in buffer mode.
- *
- * Use with iio_device_claim_buffer_mode().
- */
-void iio_device_release_buffer_mode(struct iio_dev *indio_dev)
-{
-	mutex_unlock(&to_iio_dev_opaque(indio_dev)->mlock);
-}
-EXPORT_SYMBOL_GPL(iio_device_release_buffer_mode);
-
 /**
  * iio_device_get_current_mode() - helper function providing read-only access to
  *				   the opaque @currentmode variable
diff --git a/drivers/iio/light/opt4060.c b/drivers/iio/light/opt4060.c
index 981c704e7df5..8c4a1f562a83 100644
--- a/drivers/iio/light/opt4060.c
+++ b/drivers/iio/light/opt4060.c
@@ -304,7 +304,7 @@ static int opt4060_set_driver_state(struct iio_dev *indio_dev,
 	struct opt4060_chip *chip = iio_priv(indio_dev);
 	int ret = 0;
 any_mode_retry:
-	if (iio_device_claim_buffer_mode(indio_dev)) {
+	if (!iio_device_try_claim_buffer_mode(indio_dev)) {
 		/*
 		 * This one is a *bit* hacky. If we cannot claim buffer mode,
 		 * then try direct mode so that we make sure things cannot
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 3cf340208694..d8af0456f966 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -706,8 +706,39 @@ static inline bool iio_device_claim_direct(struct iio_dev *indio_dev)
  */
 #define iio_device_release_direct(indio_dev) __iio_dev_mode_unlock(indio_dev)
 
-int iio_device_claim_buffer_mode(struct iio_dev *indio_dev);
-void iio_device_release_buffer_mode(struct iio_dev *indio_dev);
+/**
+ * iio_device_try_claim_buffer_mode - Keep device in buffer mode
+ * @indio_dev:	the iio_dev associated with the device
+ *
+ * If the device is in buffer mode it is guaranteed to stay
+ * that way until iio_device_release_buffer_mode() is called.
+ *
+ * Use with iio_device_release_buffer_mode().
+ *
+ * Returns: true on success, false on failure.
+ */
+static inline bool iio_device_try_claim_buffer_mode(struct iio_dev *indio_dev)
+{
+	__iio_dev_mode_lock(indio_dev);
+
+	if (!iio_buffer_enabled(indio_dev)) {
+		__iio_dev_mode_unlock(indio_dev);
+		return false;
+	}
+
+	return true;
+}
+
+/**
+ * iio_device_release_buffer_mode - releases claim on buffer mode
+ * @indio_dev:	the iio_dev associated with the device
+ *
+ * Release the claim. Device is no longer guaranteed to stay
+ * in buffer mode.
+ *
+ * Use with iio_device_try_claim_buffer_mode().
+ */
+#define iio_device_release_buffer_mode(indio_dev) __iio_dev_mode_unlock(indio_dev)
 
 extern const struct bus_type iio_bus_type;
 

-- 
2.52.0

[PATCH v3 4/7] iio: core: Add cleanup.h support for iio_device_claim_*()

[Kurt Borja]

Add guard classes for iio_device_claim_*() conditional locks. This will
aid drivers write safer and cleaner code when dealing with some common
patterns.

These classes are not meant to be used directly by drivers (hence the
__priv__ prefix). Instead, documented wrapper macros are provided to
enforce the use of ACQUIRE() or guard() semantics and avoid the
problematic scoped guard.

Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
 include/linux/iio/iio.h | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index d8af0456f966..c795f731f2d8 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -10,6 +10,7 @@
 #include <linux/align.h>
 #include <linux/device.h>
 #include <linux/cdev.h>
+#include <linux/cleanup.h>
 #include <linux/compiler_types.h>
 #include <linux/minmax.h>
 #include <linux/slab.h>
@@ -740,6 +741,76 @@ static inline bool iio_device_try_claim_buffer_mode(struct iio_dev *indio_dev)
  */
 #define iio_device_release_buffer_mode(indio_dev) __iio_dev_mode_unlock(indio_dev)
 
+/*
+ * These classes are not meant to be used directly by drivers (hence the
+ * __priv__ prefix). Instead, documented wrapper macros are provided bellow to
+ * enforce the use of ACQUIRE() or guard() semantics and avoid the problematic
+ * scoped guard variants.
+ */
+DEFINE_GUARD(__priv__iio_dev_mode_lock, struct iio_dev *,
+	     __iio_dev_mode_lock(_T), __iio_dev_mode_unlock(_T));
+DEFINE_GUARD_COND(__priv__iio_dev_mode_lock, _try_direct,
+		  iio_device_claim_direct(_T));
+
+/**
+ * IIO_DEV_ACQUIRE_DIRECT_MODE(_dev, _var) - Tries to acquire the direct mode
+ *                                           lock with automatic release
+ * @dev: IIO device instance
+ * @claim: Variable identifier to store acquire result
+ *
+ * Tries to acquire the direct mode lock with cleanup ACQUIRE() semantics and
+ * automatically releases it at the end of the scope. It most be always paired
+ * with IIO_DEV_ACQUIRE_ERR(), for example::
+ *
+ *	IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
+ *	if (IIO_DEV_ACQUIRE_FAILED(&claim))
+ *		return -EBUSY;
+ *
+ * ...or a more common scenario (notice scope the braces)::
+ *
+ *	switch() {
+ *	case IIO_CHAN_INFO_RAW: {
+ *		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
+ *		if (IIO_DEV_ACQUIRE_FAILED(&claim))
+ *			return -EBUSY;
+ *
+ *		...
+ *	}
+ *	case IIO_CHAN_INFO_SCALE:
+ *		...
+ *	...
+ *	}
+ *
+ * Context: Can sleep
+ */
+#define IIO_DEV_ACQUIRE_DIRECT_MODE(dev, claim) \
+	ACQUIRE(__priv__iio_dev_mode_lock_try_direct, claim)(dev)
+
+/**
+ * IIO_DEV_ACQUIRE_FAILED() - ACQUIRE_ERR() wrapper
+ * @claim_ptr: Pointer to the claim variable passed to IIO_DEV_ACQUIRE_*_MODE()
+ *
+ * Return: true if acquired the mode failed, otherwise false.
+ */
+#define IIO_DEV_ACQUIRE_FAILED(claim_ptr) \
+	ACQUIRE_ERR(__priv__iio_dev_mode_lock_try_direct, claim_ptr)
+
+/**
+ * IIO_DEV_GUARD_CURRENT_MODE - Acquires the mode lock with automatic release
+ * @_dev: IIO device instance
+ *
+ * Acquires the mode lock with cleanup guard() semantics. It is usually paired
+ * with iio_buffer_enabled().
+ *
+ * This should *not* be used to protect internal driver state and it's use in
+ * general is *strongly* discouraged. Use any of the IIO_DEV_ACQUIRE_*_MODE()
+ * variants.
+ *
+ * Context: Can sleep
+ */
+#define IIO_DEV_GUARD_CURRENT_MODE(dev) \
+	guard(__priv__iio_dev_mode_lock)(dev)
+
 extern const struct bus_type iio_bus_type;
 
 /**

-- 
2.52.0

Re: [PATCH v3 4/7] iio: core: Add cleanup.h support for iio_device_claim_*()

[Jonathan Cameron]

On Tue, 06 Jan 2026 03:06:59 -0500
Kurt Borja <kuurtb@gmail.com> wrote:

> Add guard classes for iio_device_claim_*() conditional locks. This will
> aid drivers write safer and cleaner code when dealing with some common
> patterns.
> 
> These classes are not meant to be used directly by drivers (hence the
> __priv__ prefix). Instead, documented wrapper macros are provided to
> enforce the use of ACQUIRE() or guard() semantics and avoid the
> problematic scoped guard.
> 
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
Very nice. Trivial comments inline.

J
> ---
>  include/linux/iio/iio.h | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index d8af0456f966..c795f731f2d8 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -10,6 +10,7 @@
>  #include <linux/align.h>
>  #include <linux/device.h>
>  #include <linux/cdev.h>
> +#include <linux/cleanup.h>
>  #include <linux/compiler_types.h>
>  #include <linux/minmax.h>
>  #include <linux/slab.h>
> @@ -740,6 +741,76 @@ static inline bool iio_device_try_claim_buffer_mode(struct iio_dev *indio_dev)
>   */
>  #define iio_device_release_buffer_mode(indio_dev) __iio_dev_mode_unlock(indio_dev)
>  
> +/*
> + * These classes are not meant to be used directly by drivers (hence the
> + * __priv__ prefix). Instead, documented wrapper macros are provided bellow to

below

> + * enforce the use of ACQUIRE() or guard() semantics and avoid the problematic
> + * scoped guard variants.
> + */
> +DEFINE_GUARD(__priv__iio_dev_mode_lock, struct iio_dev *,
> +	     __iio_dev_mode_lock(_T), __iio_dev_mode_unlock(_T));
> +DEFINE_GUARD_COND(__priv__iio_dev_mode_lock, _try_direct,
> +		  iio_device_claim_direct(_T));
> +
> +/**
> + * IIO_DEV_ACQUIRE_DIRECT_MODE(_dev, _var) - Tries to acquire the direct mode
> + *                                           lock with automatic release
> + * @dev: IIO device instance
> + * @claim: Variable identifier to store acquire result
> + *
> + * Tries to acquire the direct mode lock with cleanup ACQUIRE() semantics and
> + * automatically releases it at the end of the scope. It most be always paired
> + * with IIO_DEV_ACQUIRE_ERR(), for example::
> + *
> + *	IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
> + *	if (IIO_DEV_ACQUIRE_FAILED(&claim))
> + *		return -EBUSY;

I don't think we need two examples. I'd just go with the second one as
the braces is indeed something people get wrong with the other cleanup.h stuff.

> + *
> + * ...or a more common scenario (notice scope the braces)::
> + *
> + *	switch() {
> + *	case IIO_CHAN_INFO_RAW: {
> + *		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
> + *		if (IIO_DEV_ACQUIRE_FAILED(&claim))
> + *			return -EBUSY;
> + *
> + *		...
> + *	}
> + *	case IIO_CHAN_INFO_SCALE:
> + *		...
> + *	...
> + *	}
> + *
> + * Context: Can sleep
> + */
> +#define IIO_DEV_ACQUIRE_DIRECT_MODE(dev, claim) \
> +	ACQUIRE(__priv__iio_dev_mode_lock_try_direct, claim)(dev)
> +
> +/**
> + * IIO_DEV_ACQUIRE_FAILED() - ACQUIRE_ERR() wrapper
> + * @claim_ptr: Pointer to the claim variable passed to IIO_DEV_ACQUIRE_*_MODE()
> + *
> + * Return: true if acquired the mode failed, otherwise false.
> + */
> +#define IIO_DEV_ACQUIRE_FAILED(claim_ptr) \
> +	ACQUIRE_ERR(__priv__iio_dev_mode_lock_try_direct, claim_ptr)
> +
> +/**
> + * IIO_DEV_GUARD_CURRENT_MODE - Acquires the mode lock with automatic release
> + * @_dev: IIO device instance
> + *
> + * Acquires the mode lock with cleanup guard() semantics. It is usually paired
> + * with iio_buffer_enabled().
> + *
> + * This should *not* be used to protect internal driver state and it's use in
> + * general is *strongly* discouraged. Use any of the IIO_DEV_ACQUIRE_*_MODE()
> + * variants.
> + *
> + * Context: Can sleep
> + */
> +#define IIO_DEV_GUARD_CURRENT_MODE(dev) \
> +	guard(__priv__iio_dev_mode_lock)(dev)
> +
>  extern const struct bus_type iio_bus_type;
>  
>  /**
> 

Re: [PATCH v3 4/7] iio: core: Add cleanup.h support for iio_device_claim_*()

[David Lechner]

On 1/6/26 2:06 AM, Kurt Borja wrote:
> Add guard classes for iio_device_claim_*() conditional locks. This will
> aid drivers write safer and cleaner code when dealing with some common
> patterns.
> 
> These classes are not meant to be used directly by drivers (hence the
> __priv__ prefix). Instead, documented wrapper macros are provided to
> enforce the use of ACQUIRE() or guard() semantics and avoid the
> problematic scoped guard.
> 
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
>  include/linux/iio/iio.h | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index d8af0456f966..c795f731f2d8 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -10,6 +10,7 @@
>  #include <linux/align.h>
>  #include <linux/device.h>
>  #include <linux/cdev.h>
> +#include <linux/cleanup.h>
>  #include <linux/compiler_types.h>
>  #include <linux/minmax.h>
>  #include <linux/slab.h>
> @@ -740,6 +741,76 @@ static inline bool iio_device_try_claim_buffer_mode(struct iio_dev *indio_dev)
>   */
>  #define iio_device_release_buffer_mode(indio_dev) __iio_dev_mode_unlock(indio_dev)
>  
> +/*
> + * These classes are not meant to be used directly by drivers (hence the
> + * __priv__ prefix). Instead, documented wrapper macros are provided bellow to
> + * enforce the use of ACQUIRE() or guard() semantics and avoid the problematic
> + * scoped guard variants.
> + */
> +DEFINE_GUARD(__priv__iio_dev_mode_lock, struct iio_dev *,
> +	     __iio_dev_mode_lock(_T), __iio_dev_mode_unlock(_T));
> +DEFINE_GUARD_COND(__priv__iio_dev_mode_lock, _try_direct,
> +		  iio_device_claim_direct(_T));
> +
> +/**
> + * IIO_DEV_ACQUIRE_DIRECT_MODE(_dev, _var) - Tries to acquire the direct mode
> + *                                           lock with automatic release

I don't think it is usual to put the function parameters in the
doc comment like this. They don't match the actual names anyway.

> + * @dev: IIO device instance
> + * @claim: Variable identifier to store acquire result
> + *
> + * Tries to acquire the direct mode lock with cleanup ACQUIRE() semantics and
> + * automatically releases it at the end of the scope. It most be always paired
> + * with IIO_DEV_ACQUIRE_ERR(), for example::
> + *
> + *	IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
> + *	if (IIO_DEV_ACQUIRE_FAILED(&claim))
> + *		return -EBUSY;
> + *
> + * ...or a more common scenario (notice scope the braces)::
> + *
> + *	switch() {
> + *	case IIO_CHAN_INFO_RAW: {
> + *		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
> + *		if (IIO_DEV_ACQUIRE_FAILED(&claim))
> + *			return -EBUSY;
> + *
> + *		...
> + *	}
> + *	case IIO_CHAN_INFO_SCALE:
> + *		...
> + *	...
> + *	}
> + *
> + * Context: Can sleep
> + */
> +#define IIO_DEV_ACQUIRE_DIRECT_MODE(dev, claim) \
> +	ACQUIRE(__priv__iio_dev_mode_lock_try_direct, claim)(dev)
> +
> +/**
> + * IIO_DEV_ACQUIRE_FAILED() - ACQUIRE_ERR() wrapper
> + * @claim_ptr: Pointer to the claim variable passed to IIO_DEV_ACQUIRE_*_MODE()
> + *
> + * Return: true if acquired the mode failed, otherwise false.
> + */
> +#define IIO_DEV_ACQUIRE_FAILED(claim_ptr) \
> +	ACQUIRE_ERR(__priv__iio_dev_mode_lock_try_direct, claim_ptr)
> +

If we always have to add the & at the call site, could we just
put that in the macro instead? Then the parameter would just be
claim instead of claim_ptr.

Re: [PATCH v3 4/7] iio: core: Add cleanup.h support for iio_device_claim_*()

[Kurt Borja]

On Fri Jan 16, 2026 at 5:03 PM -05, David Lechner wrote:
> On 1/6/26 2:06 AM, Kurt Borja wrote:
>> Add guard classes for iio_device_claim_*() conditional locks. This will
>> aid drivers write safer and cleaner code when dealing with some common
>> patterns.
>> 
>> These classes are not meant to be used directly by drivers (hence the
>> __priv__ prefix). Instead, documented wrapper macros are provided to
>> enforce the use of ACQUIRE() or guard() semantics and avoid the
>> problematic scoped guard.
>> 
>> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>>  include/linux/iio/iio.h | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 71 insertions(+)
>> 
>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>> index d8af0456f966..c795f731f2d8 100644
>> --- a/include/linux/iio/iio.h
>> +++ b/include/linux/iio/iio.h
>> @@ -10,6 +10,7 @@
>>  #include <linux/align.h>
>>  #include <linux/device.h>
>>  #include <linux/cdev.h>
>> +#include <linux/cleanup.h>
>>  #include <linux/compiler_types.h>
>>  #include <linux/minmax.h>
>>  #include <linux/slab.h>
>> @@ -740,6 +741,76 @@ static inline bool iio_device_try_claim_buffer_mode(struct iio_dev *indio_dev)
>>   */
>>  #define iio_device_release_buffer_mode(indio_dev) __iio_dev_mode_unlock(indio_dev)
>>  
>> +/*
>> + * These classes are not meant to be used directly by drivers (hence the
>> + * __priv__ prefix). Instead, documented wrapper macros are provided bellow to
>> + * enforce the use of ACQUIRE() or guard() semantics and avoid the problematic
>> + * scoped guard variants.
>> + */
>> +DEFINE_GUARD(__priv__iio_dev_mode_lock, struct iio_dev *,
>> +	     __iio_dev_mode_lock(_T), __iio_dev_mode_unlock(_T));
>> +DEFINE_GUARD_COND(__priv__iio_dev_mode_lock, _try_direct,
>> +		  iio_device_claim_direct(_T));
>> +
>> +/**
>> + * IIO_DEV_ACQUIRE_DIRECT_MODE(_dev, _var) - Tries to acquire the direct mode
>> + *                                           lock with automatic release
>
> I don't think it is usual to put the function parameters in the
> doc comment like this. They don't match the actual names anyway.

Hi David,

This format of kernel-doc applies to function-like macros too [1]. I'll
match the name of the variables though.

>
>> + * @dev: IIO device instance
>> + * @claim: Variable identifier to store acquire result
>> + *
>> + * Tries to acquire the direct mode lock with cleanup ACQUIRE() semantics and
>> + * automatically releases it at the end of the scope. It most be always paired
>> + * with IIO_DEV_ACQUIRE_ERR(), for example::
>> + *
>> + *	IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
>> + *	if (IIO_DEV_ACQUIRE_FAILED(&claim))
>> + *		return -EBUSY;
>> + *
>> + * ...or a more common scenario (notice scope the braces)::
>> + *
>> + *	switch() {
>> + *	case IIO_CHAN_INFO_RAW: {
>> + *		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
>> + *		if (IIO_DEV_ACQUIRE_FAILED(&claim))
>> + *			return -EBUSY;
>> + *
>> + *		...
>> + *	}
>> + *	case IIO_CHAN_INFO_SCALE:
>> + *		...
>> + *	...
>> + *	}
>> + *
>> + * Context: Can sleep
>> + */
>> +#define IIO_DEV_ACQUIRE_DIRECT_MODE(dev, claim) \
>> +	ACQUIRE(__priv__iio_dev_mode_lock_try_direct, claim)(dev)
>> +
>> +/**
>> + * IIO_DEV_ACQUIRE_FAILED() - ACQUIRE_ERR() wrapper
>> + * @claim_ptr: Pointer to the claim variable passed to IIO_DEV_ACQUIRE_*_MODE()
>> + *
>> + * Return: true if acquired the mode failed, otherwise false.
>> + */
>> +#define IIO_DEV_ACQUIRE_FAILED(claim_ptr) \
>> +	ACQUIRE_ERR(__priv__iio_dev_mode_lock_try_direct, claim_ptr)
>> +
>
> If we always have to add the & at the call site, could we just
> put that in the macro instead? Then the parameter would just be
> claim instead of claim_ptr.

I'll add this in the next revision.

[1] https://docs.kernel.org/doc-guide/kernel-doc.html#function-documentation

-- 
Thanks,
 ~ Kurt

Re: [PATCH v3 4/7] iio: core: Add cleanup.h support for iio_device_claim_*()

[David Lechner]

On 1/18/26 9:23 AM, Kurt Borja wrote:
> On Fri Jan 16, 2026 at 5:03 PM -05, David Lechner wrote:
>> On 1/6/26 2:06 AM, Kurt Borja wrote:
>>> Add guard classes for iio_device_claim_*() conditional locks. This will
>>> aid drivers write safer and cleaner code when dealing with some common
>>> patterns.
>>>
>>> These classes are not meant to be used directly by drivers (hence the
>>> __priv__ prefix). Instead, documented wrapper macros are provided to
>>> enforce the use of ACQUIRE() or guard() semantics and avoid the
>>> problematic scoped guard.
>>>
>>> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>>> ---
>>>  include/linux/iio/iio.h | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 71 insertions(+)
>>>
>>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>>> index d8af0456f966..c795f731f2d8 100644
>>> --- a/include/linux/iio/iio.h
>>> +++ b/include/linux/iio/iio.h
>>> @@ -10,6 +10,7 @@
>>>  #include <linux/align.h>
>>>  #include <linux/device.h>
>>>  #include <linux/cdev.h>
>>> +#include <linux/cleanup.h>
>>>  #include <linux/compiler_types.h>
>>>  #include <linux/minmax.h>
>>>  #include <linux/slab.h>
>>> @@ -740,6 +741,76 @@ static inline bool iio_device_try_claim_buffer_mode(struct iio_dev *indio_dev)
>>>   */
>>>  #define iio_device_release_buffer_mode(indio_dev) __iio_dev_mode_unlock(indio_dev)
>>>  
>>> +/*
>>> + * These classes are not meant to be used directly by drivers (hence the
>>> + * __priv__ prefix). Instead, documented wrapper macros are provided bellow to
>>> + * enforce the use of ACQUIRE() or guard() semantics and avoid the problematic
>>> + * scoped guard variants.
>>> + */
>>> +DEFINE_GUARD(__priv__iio_dev_mode_lock, struct iio_dev *,
>>> +	     __iio_dev_mode_lock(_T), __iio_dev_mode_unlock(_T));
>>> +DEFINE_GUARD_COND(__priv__iio_dev_mode_lock, _try_direct,
>>> +		  iio_device_claim_direct(_T));
>>> +
>>> +/**
>>> + * IIO_DEV_ACQUIRE_DIRECT_MODE(_dev, _var) - Tries to acquire the direct mode
>>> + *                                           lock with automatic release
>>
>> I don't think it is usual to put the function parameters in the
>> doc comment like this. They don't match the actual names anyway.
> 
> Hi David,
> 
> This format of kernel-doc applies to function-like macros too [1]. I'll
> match the name of the variables though.

Right. And it has no parameters between the () on the first line
in that documentation.

/*
 * function_name() - Brief description of function.


So it should be just `IIO_DEV_ACQUIRE_DIRECT_MODE() - ...

>
>> + * @dev: IIO device instance
>> + * @claim: Variable identifier to store acquire result
>> + *

The parameters go below like this, which is already correct.

[PATCH v3 6/7] iio: health: max30102: Use IIO cleanup helpers

[Kurt Borja]

Use IIO_DEV_GUARD_CURRENT_MODE() cleanup helper to simplify and drop
busy-waiting code in max30102_read_raw().

Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
 drivers/iio/health/max30102.c | 33 +++++++++------------------------
 1 file changed, 9 insertions(+), 24 deletions(-)

diff --git a/drivers/iio/health/max30102.c b/drivers/iio/health/max30102.c
index 6918fcb5de2b..47da44efd68b 100644
--- a/drivers/iio/health/max30102.c
+++ b/drivers/iio/health/max30102.c
@@ -467,44 +467,29 @@ static int max30102_read_raw(struct iio_dev *indio_dev,
 			     int *val, int *val2, long mask)
 {
 	struct max30102_data *data = iio_priv(indio_dev);
-	int ret = -EINVAL;
+	int ret;
 
 	switch (mask) {
-	case IIO_CHAN_INFO_RAW:
+	case IIO_CHAN_INFO_RAW: {
 		/*
 		 * Temperature reading can only be acquired when not in
 		 * shutdown; leave shutdown briefly when buffer not running
 		 */
-any_mode_retry:
-		if (!iio_device_try_claim_buffer_mode(indio_dev)) {
-			/*
-			 * This one is a *bit* hacky. If we cannot claim buffer
-			 * mode, then try direct mode so that we make sure
-			 * things cannot concurrently change. And we just keep
-			 * trying until we get one of the modes...
-			 */
-			if (!iio_device_claim_direct(indio_dev))
-				goto any_mode_retry;
+		IIO_DEV_GUARD_CURRENT_MODE(indio_dev);
 
-			ret = max30102_get_temp(data, val, true);
-			iio_device_release_direct(indio_dev);
-		} else {
-			ret = max30102_get_temp(data, val, false);
-			iio_device_release_buffer_mode(indio_dev);
-		}
+		ret = max30102_get_temp(data, val, !iio_buffer_enabled(indio_dev));
 		if (ret)
 			return ret;
 
-		ret = IIO_VAL_INT;
-		break;
+		return IIO_VAL_INT;
+	}
 	case IIO_CHAN_INFO_SCALE:
 		*val = 1000;  /* 62.5 */
 		*val2 = 16;
-		ret = IIO_VAL_FRACTIONAL;
-		break;
+		return IIO_VAL_FRACTIONAL;
+	default:
+		return -EINVAL;
 	}
-
-	return ret;
 }
 
 static const struct iio_info max30102_info = {

-- 
2.52.0

[PATCH v3 7/7] iio: light: opt4060: Use IIO cleanup helpers

[Kurt Borja]

Use IIO_DEV_GUARD_CURRENT_MODE() cleanup helper to simplify and drop
busy-waiting code in opt4060_set_driver_state().

Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
 drivers/iio/light/opt4060.c | 52 +++++++++++++++------------------------------
 1 file changed, 17 insertions(+), 35 deletions(-)

diff --git a/drivers/iio/light/opt4060.c b/drivers/iio/light/opt4060.c
index 8c4a1f562a83..d6e915ab355d 100644
--- a/drivers/iio/light/opt4060.c
+++ b/drivers/iio/light/opt4060.c
@@ -302,41 +302,23 @@ static int opt4060_set_driver_state(struct iio_dev *indio_dev,
 				    bool continuous_irq)
 {
 	struct opt4060_chip *chip = iio_priv(indio_dev);
-	int ret = 0;
-any_mode_retry:
-	if (!iio_device_try_claim_buffer_mode(indio_dev)) {
-		/*
-		 * This one is a *bit* hacky. If we cannot claim buffer mode,
-		 * then try direct mode so that we make sure things cannot
-		 * concurrently change. And we just keep trying until we get one
-		 * of the modes...
-		 */
-		if (!iio_device_claim_direct(indio_dev))
-			goto any_mode_retry;
-		/*
-		 * This path means that we managed to claim direct mode. In
-		 * this case the buffer isn't enabled and it's okay to leave
-		 * continuous mode for sampling and/or irq.
-		 */
-		ret = opt4060_set_state_common(chip, continuous_sampling,
-					       continuous_irq);
-		iio_device_release_direct(indio_dev);
-		return ret;
-	} else {
-		/*
-		 * This path means that we managed to claim buffer mode. In
-		 * this case the buffer is enabled and irq and sampling must go
-		 * to or remain continuous, but only if the trigger is from this
-		 * device.
-		 */
-		if (!iio_trigger_validate_own_device(indio_dev->trig, indio_dev))
-			ret = opt4060_set_state_common(chip, true, true);
-		else
-			ret = opt4060_set_state_common(chip, continuous_sampling,
-						       continuous_irq);
-		iio_device_release_buffer_mode(indio_dev);
-	}
-	return ret;
+
+	IIO_DEV_GUARD_CURRENT_MODE(indio_dev);
+
+	/*
+	 * If we manage to claim buffer mode and we are using our own trigger,
+	 * IRQ and sampling must go to or remain continuous.
+	 */
+	if (iio_buffer_enabled(indio_dev) &&
+	    iio_trigger_validate_own_device(indio_dev->trig, indio_dev))
+		return opt4060_set_state_common(chip, true, true);
+
+	/*
+	 * This path means that we managed to claim direct mode. In this case
+	 * the buffer isn't enabled and it's okay to leave continuous mode for
+	 * sampling and/or irq.
+	 */
+	return opt4060_set_state_common(chip, continuous_sampling, continuous_irq);
 }
 
 /*

-- 
2.52.0

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

[Jonathan Cameron]

On Tue, 06 Jan 2026 03:06:55 -0500
Kurt Borja <kuurtb@gmail.com> 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()

I'm not a huge fan of flag days though this is entirely in direct mode
so I can just do it at the start of a cycle.

Anyhow, that's a job for another day where we can bikeshed the naming
yet again.

I do like unifying the unlock though.

Patch 5 never made the list for some reason.
https://lore.kernel.org/all/20260106-lock-impr-v3-0-1db909b192c0@gmail.com/#r

(I thought I'd accidentally deleted it!)

Thanks

Jonathan


> 
> Let me know what you think and thanks for taking a look!
> 
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> v3:
> 
>   - Reword commit message of patch 1: infallible -> unconditional.
> 
>   - Drop "*strongly*" in __iio_dev_mode_lock() kernel-doc and be a bit
>     more clear on the function's intention.
> 
>   - Keep comment about inline functions and sparse markings, but drop
>     the __cond_acquires() part, as the new implementation makes it
>     unnecessary.
> 
>   - Implement iio_device_release_*() as macros around
>     __iio_dev_mode_unlock().
> 
>   - Rename iio_device_claim_buffer_mode() ->
>     iio_device_try_claim_buffer_mode() to avoid silently breaking
>     out-of-tree drivers.
> 
>   - Drop the `_` argument prefix in new macros, as there are no name
>     conflicts.
> 
>   - Drop "dummy" from IIO_DEV_ACQUIRE_DIRECT_MODE kernel-doc, as the
>     `claim` variable does store the error value.
> 
>   - Drop IIO_DEV_ACQUIRE_BUFFER_MODE() until a driver actually needs it.
> 
>   - Rename IIO_DEV_ACQUIRE_ERR() -> IIO_DEV_ACQUIRE_FAILED() to make the
>     name more clear.
> 
>   - Rename IIO_DEV_GUARD_ANY_MODE() -> IIO_DEV_GUARD_CURRENT_MODE() to
>     make the name more clear.
> 
>   - Add missing . in iio_device_release_direct() kernel-doc.
> 
>   NOTE: Andy suggested __iio_dev_mode_*() be exported into the IIO_CORE
>         namespace. However, this cannot be done because these functions
> 	need to be called inline, so Sparse can see the __acquires() and
> 	__releases() tags.
> 
>   Happy new year to everyone :)
> 
> v2: https://lore.kernel.org/r/20251211-lock-impr-v2-0-6fb47bdaaf24@gmail.com
> 
>   - Add __iio_dev_mode_lock() (formerly iio_device_claim()) in the first
>     patch.
> 
>   - Added comments to make sure __iio_dev_mode_lock() is not used by
>     drivers to protect internal state, or in general.
> 
>   - Add patch which re-implements iio_device_claim_direct() using
>     __iio_dev_mode_lock().
> 
>   - Match iio_device_claim_buffer_mode() semantics by reimplementing it
>     in the same way as iio_device_claim_direct().
> 
>   - Guard classes now are prefixed with __priv__ to make sure drivers
>     don't use them directly.
> 
>   - Add IIO_DEV_ACQUIRE_{BUFFER,DIRECT}_MODE() documented wrappers
> 
>   - Avoid any function renames (for now).
> 
>   - Rename dummy variable `claim` instead of `busy` on vcnl4000 patch.
> 
>   - Avoid scoped guard in max30102.
> 
>   - Keep using iio_trigger_validate_own_device() insted of
>     iio_trigger_using_own() in opt4060.
> 
> v1: https://lore.kernel.org/r/20251203-lock-impr-v1-0-b4a1fd639423@gmail.com
> 
> ---
> Kurt Borja (7):
>       iio: core: Add and export __iio_dev_mode_lock()
>       iio: core: Refactor iio_device_claim_direct() implementation
>       iio: core: Match iio_device_claim_*() semantics and implementation
>       iio: core: Add cleanup.h support for iio_device_claim_*()
>       iio: light: vcnl4000: Use IIO cleanup helpers
>       iio: health: max30102: Use IIO cleanup helpers
>       iio: light: opt4060: Use IIO cleanup helpers
> 
>  drivers/iio/adc/ade9000.c                          |   2 +-
>  .../common/cros_ec_sensors/cros_ec_sensors_core.c  |   5 +-
>  drivers/iio/health/max30100.c                      |   8 +-
>  drivers/iio/health/max30102.c                      |  33 ++---
>  drivers/iio/industrialio-core.c                    |  86 +++---------
>  drivers/iio/light/opt4060.c                        |  52 +++-----
>  drivers/iio/light/vcnl4000.c                       |  49 +++----
>  include/linux/iio/iio.h                            | 145 +++++++++++++++++++--
>  8 files changed, 196 insertions(+), 184 deletions(-)
> ---
> base-commit: fb2f4eb29a258145b0336601f00509cab6e93e7c
> change-id: 20251130-lock-impr-6f22748c15e8
> 

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

[Kurt Borja]

On Fri Jan 16, 2026 at 3:33 PM -05, Jonathan Cameron wrote:
> On Tue, 06 Jan 2026 03:06:55 -0500
> Kurt Borja <kuurtb@gmail.com> 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()
>
> I'm not a huge fan of flag days though this is entirely in direct mode
> so I can just do it at the start of a cycle.
>
> Anyhow, that's a job for another day where we can bikeshed the naming
> yet again.
>
> I do like unifying the unlock though.

I can send the patch, gather some feedback and then send a rebased v2 at
the start of the next cycle (or whenever seems best).

Should be pretty trivial, after I learn a bit about semantic patches
( famous last words? :) ).

If you feel up to it, I'm up to it.

>
> Patch 5 never made the list for some reason.
> https://lore.kernel.org/all/20260106-lock-impr-v3-0-1db909b192c0@gmail.com/#r
>
> (I thought I'd accidentally deleted it!)

Yep, it seems it never reached. I'll make sure it does this time.

>
> Thanks
>
> Jonathan
>
>


-- 
Thanks,
 ~ Kurt

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

[David Lechner]

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@gmail.com>
> ---
Like Jonathan, I just had a few minor suggestions, but overall:

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

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

[Kurt Borja]

On Fri Jan 16, 2026 at 5:08 PM -05, David Lechner wrote:
> 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@gmail.com>
>> ---
> Like Jonathan, I just had a few minor suggestions, but overall:
>
> Reviewed-by: David Lechner <dlechner@baylibre.com>

Hi David,

I'll add your remarks in the next version. Thanks for all the feedback!


-- 
Thanks,
 ~ Kurt

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

[Nuno Sá]

On Tue, 2026-01-06 at 03:06 -0500, 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@gmail.com>
> ---
> v3:
> 
>   - Reword commit message of patch 1: infallible -> unconditional.
> 
>   - Drop "*strongly*" in __iio_dev_mode_lock() kernel-doc and be a bit
>     more clear on the function's intention.
> 
>   - Keep comment about inline functions and sparse markings, but drop
>     the __cond_acquires() part, as the new implementation makes it
>     unnecessary.
> 
>   - Implement iio_device_release_*() as macros around
>     __iio_dev_mode_unlock().
> 
>   - Rename iio_device_claim_buffer_mode() ->
>     iio_device_try_claim_buffer_mode() to avoid silently breaking
>     out-of-tree drivers.
> 
>   - Drop the `_` argument prefix in new macros, as there are no name
>     conflicts.
> 
>   - Drop "dummy" from IIO_DEV_ACQUIRE_DIRECT_MODE kernel-doc, as the
>     `claim` variable does store the error value.
> 
>   - Drop IIO_DEV_ACQUIRE_BUFFER_MODE() until a driver actually needs it.
> 
>   - Rename IIO_DEV_ACQUIRE_ERR() -> IIO_DEV_ACQUIRE_FAILED() to make the
>     name more clear.
> 
>   - Rename IIO_DEV_GUARD_ANY_MODE() -> IIO_DEV_GUARD_CURRENT_MODE() to
>     make the name more clear.
> 
>   - Add missing . in iio_device_release_direct() kernel-doc.
> 
>   NOTE: Andy suggested __iio_dev_mode_*() be exported into the IIO_CORE
>         namespace. However, this cannot be done because these functions
> 	need to be called inline, so Sparse can see the __acquires() and
> 	__releases() tags.
> 
>   Happy new year to everyone :)
> 
> v2: https://lore.kernel.org/r/20251211-lock-impr-v2-0-6fb47bdaaf24@gmail.com
> 
>   - Add __iio_dev_mode_lock() (formerly iio_device_claim()) in the first
>     patch.
> 
>   - Added comments to make sure __iio_dev_mode_lock() is not used by
>     drivers to protect internal state, or in general.
> 
>   - Add patch which re-implements iio_device_claim_direct() using
>     __iio_dev_mode_lock().
> 
>   - Match iio_device_claim_buffer_mode() semantics by reimplementing it
>     in the same way as iio_device_claim_direct().
> 
>   - Guard classes now are prefixed with __priv__ to make sure drivers
>     don't use them directly.
> 
>   - Add IIO_DEV_ACQUIRE_{BUFFER,DIRECT}_MODE() documented wrappers
> 
>   - Avoid any function renames (for now).
> 
>   - Rename dummy variable `claim` instead of `busy` on vcnl4000 patch.
> 
>   - Avoid scoped guard in max30102.
> 
>   - Keep using iio_trigger_validate_own_device() insted of
>     iio_trigger_using_own() in opt4060.
> 
> v1: https://lore.kernel.org/r/20251203-lock-impr-v1-0-b4a1fd639423@gmail.com
> 
> ---
> Kurt Borja (7):
>       iio: core: Add and export __iio_dev_mode_lock()
>       iio: core: Refactor iio_device_claim_direct() implementation
>       iio: core: Match iio_device_claim_*() semantics and implementation
>       iio: core: Add cleanup.h support for iio_device_claim_*()
>       iio: light: vcnl4000: Use IIO cleanup helpers
>       iio: health: max30102: Use IIO cleanup helpers
>       iio: light: opt4060: Use IIO cleanup helpers
> 
>  drivers/iio/adc/ade9000.c                          |   2 +-
>  .../common/cros_ec_sensors/cros_ec_sensors_core.c  |   5 +-
>  drivers/iio/health/max30100.c                      |   8 +-
>  drivers/iio/health/max30102.c                      |  33 ++---
>  drivers/iio/industrialio-core.c                    |  86 +++---------
>  drivers/iio/light/opt4060.c                        |  52 +++-----
>  drivers/iio/light/vcnl4000.c                       |  49 +++----
>  include/linux/iio/iio.h                            | 145 +++++++++++++++++++--
>  8 files changed, 196 insertions(+), 184 deletions(-)
> ---
> base-commit: fb2f4eb29a258145b0336601f00509cab6e93e7c
> change-id: 20251130-lock-impr-6f22748c15e8

Nothing to add from me...

Reviewed-by: Nuno Sá <nuno.sa@analog.com>

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

[Kurt Borja]

On Sun Jan 18, 2026 at 5:00 AM -05, Nuno Sá wrote:
> On Tue, 2026-01-06 at 03:06 -0500, 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@gmail.com>
>> ---
>> v3:
>> 
>>   - Reword commit message of patch 1: infallible -> unconditional.
>> 
>>   - Drop "*strongly*" in __iio_dev_mode_lock() kernel-doc and be a bit
>>     more clear on the function's intention.
>> 
>>   - Keep comment about inline functions and sparse markings, but drop
>>     the __cond_acquires() part, as the new implementation makes it
>>     unnecessary.
>> 
>>   - Implement iio_device_release_*() as macros around
>>     __iio_dev_mode_unlock().
>> 
>>   - Rename iio_device_claim_buffer_mode() ->
>>     iio_device_try_claim_buffer_mode() to avoid silently breaking
>>     out-of-tree drivers.
>> 
>>   - Drop the `_` argument prefix in new macros, as there are no name
>>     conflicts.
>> 
>>   - Drop "dummy" from IIO_DEV_ACQUIRE_DIRECT_MODE kernel-doc, as the
>>     `claim` variable does store the error value.
>> 
>>   - Drop IIO_DEV_ACQUIRE_BUFFER_MODE() until a driver actually needs it.
>> 
>>   - Rename IIO_DEV_ACQUIRE_ERR() -> IIO_DEV_ACQUIRE_FAILED() to make the
>>     name more clear.
>> 
>>   - Rename IIO_DEV_GUARD_ANY_MODE() -> IIO_DEV_GUARD_CURRENT_MODE() to
>>     make the name more clear.
>> 
>>   - Add missing . in iio_device_release_direct() kernel-doc.
>> 
>>   NOTE: Andy suggested __iio_dev_mode_*() be exported into the IIO_CORE
>>         namespace. However, this cannot be done because these functions
>> 	need to be called inline, so Sparse can see the __acquires() and
>> 	__releases() tags.
>> 
>>   Happy new year to everyone :)
>> 
>> v2: https://lore.kernel.org/r/20251211-lock-impr-v2-0-6fb47bdaaf24@gmail.com
>> 
>>   - Add __iio_dev_mode_lock() (formerly iio_device_claim()) in the first
>>     patch.
>> 
>>   - Added comments to make sure __iio_dev_mode_lock() is not used by
>>     drivers to protect internal state, or in general.
>> 
>>   - Add patch which re-implements iio_device_claim_direct() using
>>     __iio_dev_mode_lock().
>> 
>>   - Match iio_device_claim_buffer_mode() semantics by reimplementing it
>>     in the same way as iio_device_claim_direct().
>> 
>>   - Guard classes now are prefixed with __priv__ to make sure drivers
>>     don't use them directly.
>> 
>>   - Add IIO_DEV_ACQUIRE_{BUFFER,DIRECT}_MODE() documented wrappers
>> 
>>   - Avoid any function renames (for now).
>> 
>>   - Rename dummy variable `claim` instead of `busy` on vcnl4000 patch.
>> 
>>   - Avoid scoped guard in max30102.
>> 
>>   - Keep using iio_trigger_validate_own_device() insted of
>>     iio_trigger_using_own() in opt4060.
>> 
>> v1: https://lore.kernel.org/r/20251203-lock-impr-v1-0-b4a1fd639423@gmail.com
>> 
>> ---
>> Kurt Borja (7):
>>       iio: core: Add and export __iio_dev_mode_lock()
>>       iio: core: Refactor iio_device_claim_direct() implementation
>>       iio: core: Match iio_device_claim_*() semantics and implementation
>>       iio: core: Add cleanup.h support for iio_device_claim_*()
>>       iio: light: vcnl4000: Use IIO cleanup helpers
>>       iio: health: max30102: Use IIO cleanup helpers
>>       iio: light: opt4060: Use IIO cleanup helpers
>> 
>>  drivers/iio/adc/ade9000.c                          |   2 +-
>>  .../common/cros_ec_sensors/cros_ec_sensors_core.c  |   5 +-
>>  drivers/iio/health/max30100.c                      |   8 +-
>>  drivers/iio/health/max30102.c                      |  33 ++---
>>  drivers/iio/industrialio-core.c                    |  86 +++---------
>>  drivers/iio/light/opt4060.c                        |  52 +++-----
>>  drivers/iio/light/vcnl4000.c                       |  49 +++----
>>  include/linux/iio/iio.h                            | 145 +++++++++++++++++++--
>>  8 files changed, 196 insertions(+), 184 deletions(-)
>> ---
>> base-commit: fb2f4eb29a258145b0336601f00509cab6e93e7c
>> change-id: 20251130-lock-impr-6f22748c15e8
>
> Nothing to add from me...
>
> Reviewed-by: Nuno Sá <nuno.sa@analog.com>

Thank you for your feedback, Nuno!

-- 
Thanks,
 ~ Kurt