[PATCH v2] iio: proximity: aw96103: Fix early return in IRQ handler loop

Salah Triki posted 1 patch 1 month ago
drivers/iio/proximity/aw96103.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH v2] iio: proximity: aw96103: Fix early return in IRQ handler loop
Posted by Salah Triki 1 month ago
When an unrecognized proximity status is encountered in aw96103_irq(),
the default case executes a return IRQ_HANDLED. Because this happens
inside the loop over the device's channels, any remaining channels are
left unhandled, causing missed events and stale IRQ status.

Replace the return IRQ_HANDLED statement in the default case with
continue to ensure all channels are processed even if one has an
unexpected status value.

This issue was found via code inspection.

Signed-off-by: Salah Triki <salah.triki@gmail.com>
---
Changes since v1:
-Remove Fixes tag as this is hardening rather than a fix for a real-world bug.
-Mention in commit message that the issue was identified through code reading.

 drivers/iio/proximity/aw96103.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/aw96103.c b/drivers/iio/proximity/aw96103.c
index 8fbb755dcae0..b1f36a51d56f 100644
--- a/drivers/iio/proximity/aw96103.c
+++ b/drivers/iio/proximity/aw96103.c
@@ -669,7 +669,7 @@ static irqreturn_t aw96103_irq(int irq, void *data)
 				       iio_get_time_ns(indio_dev));
 			break;
 		default:
-			return IRQ_HANDLED;
+			continue;
 		}
 		aw96103->channels_arr[i].old_irq_status = curr_status;
 	}
-- 
2.43.0
Re: [PATCH v2] iio: proximity: aw96103: Fix early return in IRQ handler loop
Posted by Jonathan Cameron 1 month ago
On Sun, 23 Aug 2026 05:09:25 +0100
Salah Triki <salah.triki@gmail.com> wrote:

> When an unrecognized proximity status is encountered in aw96103_irq(),
> the default case executes a return IRQ_HANDLED. Because this happens
> inside the loop over the device's channels, any remaining channels are
> left unhandled, causing missed events and stale IRQ status.
> 
> Replace the return IRQ_HANDLED statement in the default case with
> continue to ensure all channels are processed even if one has an
> unexpected status value.
> 
> This issue was found via code inspection.
> 
> Signed-off-by: Salah Triki <salah.triki@gmail.com>
Applied to the testing branch of iio.git.

Another one I forgot for reasons I apply quicker than average (see
reply the tmp117)

- Low risk changes - either because of code (true here) or because of timing
  the tree is getting rebased anyway (also true)

Jonathan

> ---
> Changes since v1:
> -Remove Fixes tag as this is hardening rather than a fix for a real-world bug.
> -Mention in commit message that the issue was identified through code reading.
> 
>  drivers/iio/proximity/aw96103.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/proximity/aw96103.c b/drivers/iio/proximity/aw96103.c
> index 8fbb755dcae0..b1f36a51d56f 100644
> --- a/drivers/iio/proximity/aw96103.c
> +++ b/drivers/iio/proximity/aw96103.c
> @@ -669,7 +669,7 @@ static irqreturn_t aw96103_irq(int irq, void *data)
>  				       iio_get_time_ns(indio_dev));
>  			break;
>  		default:
> -			return IRQ_HANDLED;
> +			continue;
>  		}
>  		aw96103->channels_arr[i].old_irq_status = curr_status;
>  	}