[PATCH v6 0/5] iio: proximity: Add interrupt support for RFD77402

[PATCH v6 0/5] iio: proximity: Add interrupt support for RFD77402

[Shrikant Raskar via B4 Relay]

This series improves the RFD77402 ToF driver by cleaning up include
ordering, improving resource lifetime handling, switching to kernel
polling helpers, and adding optional interrupt-driven operation.

Changes in v6:
- Convert rfd77402_data comments to proper kernel-doc format.
- Re-order the patch sequence as suggested.
- Add missing header files.
- Refactor code to get rid of the i2c_set_clientdata() and 
respective getter calls.

Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
---
Changelog:

v4 to v5:
- Add precursor patch to reorder includes before functional changes.
- Use devm_mutex_init() for proper lifetime management.
- Address maintainer feedback on polling helper usage.
- Remove dead code from interrupt_handler.
- Add blank line in rfd77402_wait_for_irq.
- Update measurement timeout comment.
- Add helper function for result polling.
- Fix comment format in rfd77402_init.
- Remove 'data->irq_en = false', as it already initialized by kzalloc.
- Improve documentation of private driver data.
Link to v4: https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-0-42cd54359e9f@gmail.com/

v3 to v4:
- No code change.
Link to v3: https://lore.kernel.org/all/20251221083902.134098-1-raskar.shree97@gmail.com/

v2 to v3:
- Add 'Reviewed-by' tag to dt-binding patch.
- Update commit message in OF device ID patch.
- Update commit message in the third patch.
- Replace rfd77402_result_polling() with read_poll_timeout().
- Add 'struct rfd77402_data' details in kernel-doc format.
- Arrange includes in order.
- Add comment for completion timeout value.
- Remove blank lines.
- Indent the comments to code.
- Convert mutex_init() to devm_mutex_init().
- Remove 'IRQF_TRIGGER_FALLING' flag from devm_request_threaded_irq().
- Drop the duplicate message.
- Replace 'dev_info' with 'dev_dbg()'.
- Update 'dev_id' to 'pdata' in rfd77402_interrupt_handler().
- Drop 'interrupt mode' comment
- Use 'if(ret)' instead of 'if(ret < 0) for consistency.
- Use 'return i2c_smbus_write_byte_data()' in 'rfd77402_config_irq'.
Link to v2: https://lore.kernel.org/all/20251130153712.6792-1-raskar.shree97@gmail.com/

v1 to v2:
- Fix commit message for dt-binding patch
- Update interrupt description in dt-binding
- Add 'vdd-supply' to 'required' property in dt-binding
- Add patch for moving polling implementation to helper
- Add helper rfd77402_wait_for_irq()
- Code refactoring
- Return failure if request IRQ fail
Link to v1: https://lore.kernel.org/all/20251126031440.30065-1-raskar.shree97@gmail.com/

---
Shrikant Raskar (5):
      iio: proximity: rfd77402: Reorder header includes
      iio: proximity: rfd77402: Use kernel helper for result polling
      iio: proximity: rfd77402: Use devm-managed mutex initialization
      iio: proximity: rfd77402: Document device private data structure
      iio: proximity: rfd77402: Add interrupt handling support

 drivers/iio/proximity/rfd77402.c | 170 ++++++++++++++++++++++++++++++++-------
 1 file changed, 143 insertions(+), 27 deletions(-)
---
base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
change-id: 20260121-b4-rfd77402_v5-558b8e28c387

Best regards,
-- 
Shrikant Raskar <raskar.shree97@gmail.com>

[PATCH v6 1/5] iio: proximity: rfd77402: Reorder header includes

[Shrikant Raskar via B4 Relay]

From: Shrikant Raskar <raskar.shree97@gmail.com>

Reorder header includes to follow kernel include
ordering conventions.

Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
---
 drivers/iio/proximity/rfd77402.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/proximity/rfd77402.c b/drivers/iio/proximity/rfd77402.c
index aff60a3c1a6f..69cc1505b964 100644
--- a/drivers/iio/proximity/rfd77402.c
+++ b/drivers/iio/proximity/rfd77402.c
@@ -10,9 +10,9 @@
  * https://media.digikey.com/pdf/Data%20Sheets/RF%20Digital%20PDFs/RFD77402.pdf
  */
 
-#include <linux/module.h>
-#include <linux/i2c.h>
 #include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
 
 #include <linux/iio/iio.h>
 

-- 
2.43.0

[PATCH v6 2/5] iio: proximity: rfd77402: Use kernel helper for result polling

[Shrikant Raskar via B4 Relay]

From: Shrikant Raskar <raskar.shree97@gmail.com>

Replace the manually written polling loop with read_poll_timeout(),
the kernel's standard helper for waiting on hardware status.
Move the polling logic into a dedicated helper function, as it will
be reused by future updates.

This makes the code easier to read and avoids repeating the same
polling code in the driver.

Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
---
 drivers/iio/proximity/rfd77402.c | 34 +++++++++++++++++++---------------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/iio/proximity/rfd77402.c b/drivers/iio/proximity/rfd77402.c
index 69cc1505b964..716c9330b14e 100644
--- a/drivers/iio/proximity/rfd77402.c
+++ b/drivers/iio/proximity/rfd77402.c
@@ -12,6 +12,7 @@
 
 #include <linux/delay.h>
 #include <linux/i2c.h>
+#include <linux/iopoll.h>
 #include <linux/module.h>
 
 #include <linux/iio/iio.h>
@@ -110,10 +111,23 @@ static int rfd77402_set_state(struct i2c_client *client, u8 state, u16 check)
 	return 0;
 }
 
-static int rfd77402_measure(struct i2c_client *client)
+static int rfd77402_wait_for_result(struct rfd77402_data *data)
 {
+	struct i2c_client *client = data->client;
+	int ret;
+
+	return read_poll_timeout(i2c_smbus_read_byte_data, ret,
+				 ret & RFD77402_ICSR_RESULT,
+				 10 * USEC_PER_MSEC,
+				 10 * 10 * USEC_PER_MSEC,
+				 false,
+				 client, RFD77402_ICSR);
+}
+
+static int rfd77402_measure(struct rfd77402_data *data)
+{
+	struct i2c_client *client = data->client;
 	int ret;
-	int tries = 10;
 
 	ret = rfd77402_set_state(client, RFD77402_CMD_MCPU_ON,
 				 RFD77402_STATUS_MCPU_ON);
@@ -126,19 +140,9 @@ static int rfd77402_measure(struct i2c_client *client)
 	if (ret < 0)
 		goto err;
 
-	while (tries-- > 0) {
-		ret = i2c_smbus_read_byte_data(client, RFD77402_ICSR);
-		if (ret < 0)
-			goto err;
-		if (ret & RFD77402_ICSR_RESULT)
-			break;
-		msleep(20);
-	}
-
-	if (tries < 0) {
-		ret = -ETIMEDOUT;
+	ret = rfd77402_wait_for_result(data);
+	if (ret < 0)
 		goto err;
-	}
 
 	ret = i2c_smbus_read_word_data(client, RFD77402_RESULT_R);
 	if (ret < 0)
@@ -168,7 +172,7 @@ static int rfd77402_read_raw(struct iio_dev *indio_dev,
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
 		mutex_lock(&data->lock);
-		ret = rfd77402_measure(data->client);
+		ret = rfd77402_measure(data);
 		mutex_unlock(&data->lock);
 		if (ret < 0)
 			return ret;

-- 
2.43.0

[PATCH v6 3/5] iio: proximity: rfd77402: Use devm-managed mutex initialization

[Shrikant Raskar via B4 Relay]

From: Shrikant Raskar <raskar.shree97@gmail.com>

Use devm_mutex_init() to tie the mutex lifetime to the device and
simplify resource lifetime management.

Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
---
 drivers/iio/proximity/rfd77402.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/rfd77402.c b/drivers/iio/proximity/rfd77402.c
index 716c9330b14e..fce85f783ab4 100644
--- a/drivers/iio/proximity/rfd77402.c
+++ b/drivers/iio/proximity/rfd77402.c
@@ -279,7 +279,10 @@ static int rfd77402_probe(struct i2c_client *client)
 
 	data = iio_priv(indio_dev);
 	data->client = client;
-	mutex_init(&data->lock);
+
+	ret = devm_mutex_init(&client->dev, &data->lock);
+	if (ret)
+		return ret;
 
 	indio_dev->info = &rfd77402_info;
 	indio_dev->channels = rfd77402_channels;

-- 
2.43.0

[PATCH v6 4/5] iio: proximity: rfd77402: Document device private data structure

[Shrikant Raskar via B4 Relay]

From: Shrikant Raskar <raskar.shree97@gmail.com>

Add kernel-doc style comments for struct rfd77402_data to describe
the purpose of each member.

Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
---
 drivers/iio/proximity/rfd77402.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/rfd77402.c b/drivers/iio/proximity/rfd77402.c
index fce85f783ab4..dd57156a7859 100644
--- a/drivers/iio/proximity/rfd77402.c
+++ b/drivers/iio/proximity/rfd77402.c
@@ -77,9 +77,13 @@ static const struct {
 	{RFD77402_HFCFG_3,	0x45d4},
 };
 
+/**
+ * struct rfd77402_data - device-specific data for the RFD77402 sensor
+ * @client: I2C client handle
+ * @lock: mutex to serialize sensor reads
+ */
 struct rfd77402_data {
 	struct i2c_client *client;
-	/* Serialize reads from the sensor */
 	struct mutex lock;
 };
 

-- 
2.43.0

[PATCH v6 5/5] iio: proximity: rfd77402: Add interrupt handling support

[Shrikant Raskar via B4 Relay]

From: Shrikant Raskar <raskar.shree97@gmail.com>

Add interrupt handling support to enable event-driven data acquisition
instead of continuous polling. This improves responsiveness, reduces
CPU overhead, and supports low-power operation by allowing the system
to remain idle until an interrupt occurs.

Signed-off-by: Shrikant Raskar <raskar.shree97@gmail.com>
---
 drivers/iio/proximity/rfd77402.c | 121 ++++++++++++++++++++++++++++++++++++---
 1 file changed, 113 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/proximity/rfd77402.c b/drivers/iio/proximity/rfd77402.c
index dd57156a7859..7de6faad2b22 100644
--- a/drivers/iio/proximity/rfd77402.c
+++ b/drivers/iio/proximity/rfd77402.c
@@ -6,20 +6,28 @@
  *
  * 7-bit I2C slave address 0x4c
  *
- * TODO: interrupt
  * https://media.digikey.com/pdf/Data%20Sheets/RF%20Digital%20PDFs/RFD77402.pdf
  */
 
+#include <linux/bits.h>
+#include <linux/completion.h>
 #include <linux/delay.h>
+#include <linux/dev_printk.h>
+#include <linux/errno.h>
 #include <linux/i2c.h>
+#include <linux/interrupt.h>
 #include <linux/iopoll.h>
+#include <linux/jiffies.h>
 #include <linux/module.h>
+#include <linux/types.h>
 
 #include <linux/iio/iio.h>
 
 #define RFD77402_DRV_NAME "rfd77402"
 
 #define RFD77402_ICSR		0x00 /* Interrupt Control Status Register */
+#define RFD77402_ICSR_CLR_CFG   BIT(0)
+#define RFD77402_ICSR_CLR_TYPE  BIT(1)
 #define RFD77402_ICSR_INT_MODE	BIT(2)
 #define RFD77402_ICSR_INT_POL	BIT(3)
 #define RFD77402_ICSR_RESULT	BIT(4)
@@ -27,6 +35,12 @@
 #define RFD77402_ICSR_H2M_MSG	BIT(6)
 #define RFD77402_ICSR_RESET	BIT(7)
 
+#define RFD77402_IER		0x02
+#define RFD77402_IER_RESULT	BIT(0)
+#define RFD77402_IER_M2H_MSG	BIT(1)
+#define RFD77402_IER_H2M_MSG	BIT(2)
+#define RFD77402_IER_RESET	BIT(3)
+
 #define RFD77402_CMD_R		0x04
 #define RFD77402_CMD_SINGLE	0x01
 #define RFD77402_CMD_STANDBY	0x10
@@ -81,10 +95,14 @@ static const struct {
  * struct rfd77402_data - device-specific data for the RFD77402 sensor
  * @client: I2C client handle
  * @lock: mutex to serialize sensor reads
+ * @completion: completion used for interrupt-driven measurements
+ * @irq_en: indicates whether interrupt mode is enabled
  */
 struct rfd77402_data {
 	struct i2c_client *client;
 	struct mutex lock;
+	struct completion completion;
+	bool irq_en;
 };
 
 static const struct iio_chan_spec rfd77402_channels[] = {
@@ -95,6 +113,41 @@ static const struct iio_chan_spec rfd77402_channels[] = {
 	},
 };
 
+static irqreturn_t rfd77402_interrupt_handler(int irq, void *pdata)
+{
+	struct rfd77402_data *data = pdata;
+	int ret;
+
+	ret = i2c_smbus_read_byte_data(data->client, RFD77402_ICSR);
+	if (ret < 0)
+		return IRQ_NONE;
+
+	/* Check if the interrupt is from our device */
+	if (!(ret & RFD77402_ICSR_RESULT))
+		return IRQ_NONE;
+
+	/* Signal completion of measurement */
+	complete(&data->completion);
+	return IRQ_HANDLED;
+}
+
+static int rfd77402_wait_for_irq(struct rfd77402_data *data)
+{
+	int ret;
+
+	/*
+	 * According to RFD77402 Datasheet v1.8,
+	 * Section 3.1.1 "Single Measure" (Figure: Single Measure Flow Chart),
+	 * the suggested timeout for single measure is 100 ms.
+	 */
+	ret = wait_for_completion_timeout(&data->completion,
+					  msecs_to_jiffies(100));
+	if (ret == 0)
+		return -ETIMEDOUT;
+
+	return 0;
+}
+
 static int rfd77402_set_state(struct i2c_client *client, u8 state, u16 check)
 {
 	int ret;
@@ -120,6 +173,11 @@ static int rfd77402_wait_for_result(struct rfd77402_data *data)
 	struct i2c_client *client = data->client;
 	int ret;
 
+	if (data->irq_en) {
+		reinit_completion(&data->completion);
+		return rfd77402_wait_for_irq(data);
+	}
+
 	return read_poll_timeout(i2c_smbus_read_byte_data, ret,
 				 ret & RFD77402_ICSR_RESULT,
 				 10 * USEC_PER_MSEC,
@@ -196,8 +254,20 @@ static const struct iio_info rfd77402_info = {
 	.read_raw = rfd77402_read_raw,
 };
 
-static int rfd77402_init(struct i2c_client *client)
+static int rfd77402_config_irq(struct i2c_client *client, u8 csr, u8 ier)
 {
+	int ret;
+
+	ret = i2c_smbus_write_byte_data(client, RFD77402_ICSR, csr);
+	if (ret)
+		return ret;
+
+	return i2c_smbus_write_byte_data(client, RFD77402_IER, ier);
+}
+
+static int rfd77402_init(struct rfd77402_data *data)
+{
+	struct i2c_client *client = data->client;
 	int ret, i;
 
 	ret = rfd77402_set_state(client, RFD77402_CMD_STANDBY,
@@ -205,10 +275,26 @@ static int rfd77402_init(struct i2c_client *client)
 	if (ret < 0)
 		return ret;
 
-	/* configure INT pad as push-pull, active low */
-	ret = i2c_smbus_write_byte_data(client, RFD77402_ICSR,
-					RFD77402_ICSR_INT_MODE);
-	if (ret < 0)
+	if (data->irq_en) {
+		/*
+		 * Enable interrupt mode:
+		 * - Configure ICSR for auto-clear on read and
+		 *   push-pull output
+		 * - Enable "result ready" interrupt in IER
+		 */
+		ret = rfd77402_config_irq(client,
+					  RFD77402_ICSR_CLR_CFG |
+					  RFD77402_ICSR_INT_MODE,
+					  RFD77402_IER_RESULT);
+	} else {
+		/*
+		 * Disable all interrupts:
+		 * - Clear ICSR configuration
+		 * - Disable all interrupts in IER
+		 */
+		ret = rfd77402_config_irq(client, 0, 0);
+	}
+	if (ret)
 		return ret;
 
 	/* I2C configuration */
@@ -288,13 +374,29 @@ static int rfd77402_probe(struct i2c_client *client)
 	if (ret)
 		return ret;
 
+	init_completion(&data->completion);
+
+	if (client->irq > 0) {
+		ret = devm_request_threaded_irq(&client->dev, client->irq,
+						NULL, rfd77402_interrupt_handler,
+						IRQF_ONESHOT,
+						"rfd77402", data);
+		if (ret)
+			return ret;
+
+		data->irq_en = true;
+		dev_dbg(&client->dev, "Using interrupt mode\n");
+	} else {
+		dev_dbg(&client->dev, "Using polling mode\n");
+	}
+
 	indio_dev->info = &rfd77402_info;
 	indio_dev->channels = rfd77402_channels;
 	indio_dev->num_channels = ARRAY_SIZE(rfd77402_channels);
 	indio_dev->name = RFD77402_DRV_NAME;
 	indio_dev->modes = INDIO_DIRECT_MODE;
 
-	ret = rfd77402_init(client);
+	ret = rfd77402_init(data);
 	if (ret < 0)
 		return ret;
 
@@ -312,7 +414,10 @@ static int rfd77402_suspend(struct device *dev)
 
 static int rfd77402_resume(struct device *dev)
 {
-	return rfd77402_init(to_i2c_client(dev));
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct rfd77402_data *data = iio_priv(indio_dev);
+
+	return rfd77402_init(data);
 }
 
 static DEFINE_SIMPLE_DEV_PM_OPS(rfd77402_pm_ops, rfd77402_suspend,

-- 
2.43.0

Re: [PATCH v6 1/5] iio: proximity: rfd77402: Reorder header includes

[Andy Shevchenko]

On Wed, Jan 21, 2026 at 02:05:41AM +0530, Shrikant Raskar via B4 Relay wrote:

> Reorder header includes to follow kernel include
> ordering conventions.

FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 2/5] iio: proximity: rfd77402: Use kernel helper for result polling

[Andy Shevchenko]

On Wed, Jan 21, 2026 at 02:05:42AM +0530, Shrikant Raskar via B4 Relay wrote:

> Replace the manually written polling loop with read_poll_timeout(),
> the kernel's standard helper for waiting on hardware status.
> Move the polling logic into a dedicated helper function, as it will
> be reused by future updates.
> 
> This makes the code easier to read and avoids repeating the same
> polling code in the driver.

It has some repetitions, I would rephrase as:

  Replace the manually written polling loop with read_poll_timeout(),
  the kernel's standard helper for waiting on hardware status. This
  makes the code easier to read.

  Move the polling logic into a dedicated helper function, as it will
  be reused by future updates.

(also mind the blank lines and paragraphs).

...

> +static int rfd77402_wait_for_result(struct rfd77402_data *data)
>  {
> +	struct i2c_client *client = data->client;

> +	int ret;

I would named it "data" to distinguish from the usual returned code of the calls,
so like in more verbose case

	int data;
	int ret;

	ret = read_poll_timeout(..., data, data & ..., ...);
	if (data < 0)
		return data;
	if (ret)
		return ret;

> +	return read_poll_timeout(i2c_smbus_read_byte_data, ret,
> +				 ret & RFD77402_ICSR_RESULT,

'data' (ex-"ret") may be negative and this will be triggered.
I think you want 'data < 0 || (data & RFD77402_ICSR_RESULT)

> +				 10 * USEC_PER_MSEC,
> +				 10 * 10 * USEC_PER_MSEC,

This makes sleeps shorter by 2. Why?

> +				 false,
> +				 client, RFD77402_ICSR);
> +}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 3/5] iio: proximity: rfd77402: Use devm-managed mutex initialization

[Andy Shevchenko]

On Wed, Jan 21, 2026 at 02:05:43AM +0530, Shrikant Raskar via B4 Relay wrote:

> Use devm_mutex_init() to tie the mutex lifetime to the device and
> simplify resource lifetime management.

I believe it's currently more about debugging mutexes.

See how other commits in IIO look like

  commit 6e43c10675d876a5fb71e57a9bcca9533fccccd9
  Author: Nuno Sá <nuno.sa@analog.com>
  Date:   Tue Nov 4 15:35:13 2025 +0000

    iio: dac: ad5446: Make use of devm_mutex_init()

    Use devm_mutex_init() which is helpful with CONFIG_DEBUG_MUTEXES.

With the commit message being rewritten,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 4/5] iio: proximity: rfd77402: Document device private data structure

[Andy Shevchenko]

On Wed, Jan 21, 2026 at 02:05:44AM +0530, Shrikant Raskar via B4 Relay wrote:

> Add kernel-doc style comments for struct rfd77402_data to describe
> the purpose of each member.

Assuming checkpatch.pl doesn't complain (see below why),
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

...

> +/**
> + * struct rfd77402_data - device-specific data for the RFD77402 sensor
> + * @client: I2C client handle
> + * @lock: mutex to serialize sensor reads
> + */
>  struct rfd77402_data {
>  	struct i2c_client *client;
> -	/* Serialize reads from the sensor */

Not sure if this can be removed due to some checkpatch checks.
Have you run it to verify?

>  	struct mutex lock;
>  };

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 4/5] iio: proximity: rfd77402: Document device private data structure

[Shrikant]

On Wed, Jan 21, 2026 at 2:48 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Wed, Jan 21, 2026 at 02:05:44AM +0530, Shrikant Raskar via B4 Relay wrote:
>
> > Add kernel-doc style comments for struct rfd77402_data to describe
> > the purpose of each member.
>
> Assuming checkpatch.pl doesn't complain (see below why),
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> ...
>
> > +/**
> > + * struct rfd77402_data - device-specific data for the RFD77402 sensor
> > + * @client: I2C client handle
> > + * @lock: mutex to serialize sensor reads
> > + */
> >  struct rfd77402_data {
> >       struct i2c_client *client;
> > -     /* Serialize reads from the sensor */
>
> Not sure if this can be removed due to some checkpatch checks.
> Have you run it to verify?
Yes, I verified using checkpatch and it did not complain.

Regards,
Shrikant

Re: [PATCH v6 1/5] iio: proximity: rfd77402: Reorder header includes

[Jonathan Cameron]

On Wed, 21 Jan 2026 10:54:00 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Wed, Jan 21, 2026 at 02:05:41AM +0530, Shrikant Raskar via B4 Relay wrote:
> 
> > Reorder header includes to follow kernel include
> > ordering conventions.  
> 
> FWIW,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> 

Patches 1 and 2 were already queued up.  I've rebuilt the merge
in my tree to drop patch 2 without breaking the rest of the history.

Shrikant, it is common for maintainer to pick up the early
part of a series whilst later parts still need more work.
If that happens, please rebase on the appropriate tree or
just drop those patches form your series that have already been
applied. Otherwise this mess happens where new review comes
in. Review is always good, but it should be clear if it
is on applied patches or not!

Jonathan

Re: [PATCH v6 1/5] iio: proximity: rfd77402: Reorder header includes

[Shrikant]

On Fri, Jan 23, 2026 at 2:27 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Wed, 21 Jan 2026 10:54:00 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Wed, Jan 21, 2026 at 02:05:41AM +0530, Shrikant Raskar via B4 Relay wrote:
> >
> > > Reorder header includes to follow kernel include
> > > ordering conventions.
> >
> > FWIW,
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> >
>
> Patches 1 and 2 were already queued up.  I've rebuilt the merge
> in my tree to drop patch 2 without breaking the rest of the history.
>
> Shrikant, it is common for maintainer to pick up the early
> part of a series whilst later parts still need more work.
> If that happens, please rebase on the appropriate tree or
> just drop those patches form your series that have already been
> applied. Otherwise this mess happens where new review comes
> in. Review is always good, but it should be clear if it
> is on applied patches or not!
>
Sorry for creating the confusion, the patches 1 and 2 which were
applied in v4 were dropped from v5 onwards as per your suggestion.
Please see the links of the accepted patches for your reference.
1. https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-1-42cd54359e9f@gmail.com/
2. https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-2-42cd54359e9f@gmail.com/

As per reviewer comments , I have split the existing patches into
multiple commits like:
1. Added pre-cursor commit for include order
2. Added separate commit for devm mutex initialization
3. Added separate commit for kernel-doc for privata data.

Because of these separated commits, the total number of
patches in series are still 5.

Regards,
Shrikant

Re: [PATCH v6 1/5] iio: proximity: rfd77402: Reorder header includes

[Jonathan Cameron]

On Fri, 23 Jan 2026 09:12:31 +0530
Shrikant <raskar.shree97@gmail.com> wrote:

> On Fri, Jan 23, 2026 at 2:27 AM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Wed, 21 Jan 2026 10:54:00 +0200
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> >  
> > > On Wed, Jan 21, 2026 at 02:05:41AM +0530, Shrikant Raskar via B4 Relay wrote:
> > >  
> > > > Reorder header includes to follow kernel include
> > > > ordering conventions.  
> > >
> > > FWIW,
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > >  
> >
> > Patches 1 and 2 were already queued up.  I've rebuilt the merge
> > in my tree to drop patch 2 without breaking the rest of the history.
> >
> > Shrikant, it is common for maintainer to pick up the early
> > part of a series whilst later parts still need more work.
> > If that happens, please rebase on the appropriate tree or
> > just drop those patches form your series that have already been
> > applied. Otherwise this mess happens where new review comes
> > in. Review is always good, but it should be clear if it
> > is on applied patches or not!
> >  
> Sorry for creating the confusion, the patches 1 and 2 which were
> applied in v4 were dropped from v5 onwards as per your suggestion.
> Please see the links of the accepted patches for your reference.
> 1. https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-1-42cd54359e9f@gmail.com/
> 2. https://lore.kernel.org/all/20260101-b4-rfd77402_irq-v4-2-42cd54359e9f@gmail.com/
> 
> As per reviewer comments , I have split the existing patches into
> multiple commits like:
> 1. Added pre-cursor commit for include order
> 2. Added separate commit for devm mutex initialization
> 3. Added separate commit for kernel-doc for privata data.
> 
> Because of these separated commits, the total number of
> patches in series are still 5.
Ah ok so in general good. I guess you missed that I mailed to say I picked up a few
more in v5.
https://lore.kernel.org/all/20260116200921.7494025b@jic23-huawei/

These things happen so don't worry about it. I was just grumpy last night :(

Feeling much better now I've spent a few more hours getting on top of the
backlog for this cycle!

Jonathan
> 
> Regards,
> Shrikant
> 

Re: [PATCH v6 2/5] iio: proximity: rfd77402: Use kernel helper for result polling

[Shrikant]

>
> > +                              10 * USEC_PER_MSEC,
> > +                              10 * 10 * USEC_PER_MSEC,
>
> This makes sleeps shorter by 2. Why?
I have considered the timeout values from the RFD77402 datasheet.
The timeout values mentioned in section 3.1.1 Single Measure are as below:
1. Every Status Check = 10ms
2. Whole Flow = 100 ms

Regards,
Shrikant

Re: [PATCH v6 2/5] iio: proximity: rfd77402: Use kernel helper for result polling

[Andy Shevchenko]

On Sat, Jan 24, 2026 at 10:26:04PM +0530, Shrikant wrote:

...

> > > +                              10 * USEC_PER_MSEC,
> > > +                              10 * 10 * USEC_PER_MSEC,
> >
> > This makes sleeps shorter by 2. Why?
> I have considered the timeout values from the RFD77402 datasheet.
> The timeout values mentioned in section 3.1.1 Single Measure are as below:
> 1. Every Status Check = 10ms
> 2. Whole Flow = 100 ms

So, you should do this in a separate change explaining this.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 2/5] iio: proximity: rfd77402: Use kernel helper for result polling

[Shrikant]

On Mon, Jan 26, 2026 at 3:14 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Sat, Jan 24, 2026 at 10:26:04PM +0530, Shrikant wrote:
>
> ...
>
> > > > +                              10 * USEC_PER_MSEC,
> > > > +                              10 * 10 * USEC_PER_MSEC,
> > >
> > > This makes sleep shorter by 2. Why?
> > I have considered the timeout values from the RFD77402 datasheet.
> > The timeout values mentioned in section 3.1.1 Single Measure are as below:
> > 1. Every Status Check = 10ms
> > 2. Whole Flow = 100 ms
>
> So, you should do this in a separate change explaining this.
In that case, I can add a small preparatory patch before the
“Use kernel helper for result polling” patch to adjust the
polling interval according to the datasheet.

This would mean changing the existing polling loop, for example:
diff --git a/drivers/iio/proximity/rfd77402.c b/drivers/iio/proximity/rfd77402.c
index 69cc1505b964..3e14660a4bb1 100644
--- a/drivers/iio/proximity/rfd77402.c
+++ b/drivers/iio/proximity/rfd77402.c
@@ -132,7 +132,7 @@ static int rfd77402_measure(struct i2c_client *client)
                        goto err;
                if (ret & RFD77402_ICSR_RESULT)
                        break;
-               msleep(20);
+               msleep(10);
        }

        if (tries < 0) {

However, this change would then be removed in the very next patch
when the polling loop is replaced by read_poll_timeout().I just want
to confirm that this temporary change–then–removal is acceptable?

Regards,
Shrikant

Re: [PATCH v6 2/5] iio: proximity: rfd77402: Use kernel helper for result polling

[Andy Shevchenko]

On Mon, Jan 26, 2026 at 08:58:07PM +0530, Shrikant wrote:
> On Mon, Jan 26, 2026 at 3:14 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Sat, Jan 24, 2026 at 10:26:04PM +0530, Shrikant wrote:

...

> > > > > +                              10 * USEC_PER_MSEC,
> > > > > +                              10 * 10 * USEC_PER_MSEC,
> > > >
> > > > This makes sleep shorter by 2. Why?
> > > I have considered the timeout values from the RFD77402 datasheet.
> > > The timeout values mentioned in section 3.1.1 Single Measure are as below:
> > > 1. Every Status Check = 10ms
> > > 2. Whole Flow = 100 ms
> >
> > So, you should do this in a separate change explaining this.
> In that case, I can add a small preparatory patch before the
> “Use kernel helper for result polling” patch to adjust the
> polling interval according to the datasheet.
> 
> This would mean changing the existing polling loop, for example:
> diff --git a/drivers/iio/proximity/rfd77402.c b/drivers/iio/proximity/rfd77402.c
> index 69cc1505b964..3e14660a4bb1 100644
> --- a/drivers/iio/proximity/rfd77402.c
> +++ b/drivers/iio/proximity/rfd77402.c
> @@ -132,7 +132,7 @@ static int rfd77402_measure(struct i2c_client *client)
>                         goto err;
>                 if (ret & RFD77402_ICSR_RESULT)
>                         break;
> -               msleep(20);
> +               msleep(10);
>         }
> 
>         if (tries < 0) {
> 
> However, this change would then be removed in the very next patch
> when the polling loop is replaced by read_poll_timeout().I just want
> to confirm that this temporary change–then–removal is acceptable?

Yes. These two will be quite different semantically.

-- 
With Best Regards,
Andy Shevchenko