Re: [PATCH v7 09/10] iio: pressure: dps310: implement .hwfifo_flush_to_buffer()

[Rupesh Majhi <zoone.rupert@gmail.com>]

On Tue, 22 Sep 2026 00:53:47 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> Adding the guard is fine - we kicked that back a while ago simply
> due to lack of users. Is there a path to annotating the non
> ACQUIRE.. functions to expose the right information to clang?

Yes, with the change below. dps310 then builds clean using
iio_device_try_claim_buffer_mode() and iio_device_release_buffer_mode(),
and clang warns on a missing or unbalanced release.

context_lock_struct() is needed because clang rejects the existing
__acquires(indio_dev) on a type that is not a lock. The header
suppression list hides that today.

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -2252,6 +2252,7 @@ EXPORT_SYMBOL_GPL(__devm_iio_device_register);
  * iio_device_try_claim_buffer_mode() pairs or related helpers instead.
  */
 void __iio_dev_mode_lock(struct iio_dev *indio_dev)
+	__no_context_analysis
 {
 	mutex_lock(&to_iio_dev_opaque(indio_dev)->mlock);
 }
@@ -2262,6 +2263,7 @@ EXPORT_SYMBOL_GPL(__iio_dev_mode_lock);
  * @indio_dev: the iio_dev associated with the device
  */
 void __iio_dev_mode_unlock(struct iio_dev *indio_dev)
+	__no_context_analysis
 {
 	mutex_unlock(&to_iio_dev_opaque(indio_dev)->mlock);
 }
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -610,6 +610,8 @@ struct iio_buffer_setup_ops {
 				   const unsigned long *scan_mask);
 };
 
+context_lock_struct(iio_dev);
+
 /**
  * struct iio_dev - industrial I/O device
  * @modes:		[DRIVER] bitmask listing all the operating modes
@@ -726,6 +728,7 @@ void __iio_dev_mode_unlock(struct iio_dev *indio_dev) __releases(indio_dev);
  * Returns: true on success, false on failure.
  */
 static inline bool iio_device_claim_direct(struct iio_dev *indio_dev)
+	__cond_acquires(true, indio_dev)
 {
 	__iio_dev_mode_lock(indio_dev);
 
@@ -760,6 +763,7 @@ static inline bool iio_device_claim_direct(struct iio_dev *indio_dev)
  * Returns: true on success, false on failure.
  */
 static inline bool iio_device_try_claim_buffer_mode(struct iio_dev *indio_dev)
+	__cond_acquires(true, indio_dev)
 {
 	__iio_dev_mode_lock(indio_dev);
 

> I did similar for sparse and at least the direct_mode claims
> a while back. This might be a case of it just gets too complex
> though and the compiler fails to figure out what is wrong.

It holds up. drivers/iio (allmodconfig) with the analysis on for every
file goes from 254 warnings to 11, and none of the 11 are the mode lock.

If that works for you, v9 starts with this as a core patch and dps310
uses the named claim instead of a new guard.

Rupesh