From: Joshua Crofts <joshua.crofts1@gmail.com>

Currently in the function opt3001_get_processed(), there is a check
that directly returns -ETIMEDOUT if the conversion IRQ times out,
completely bypassing the err label, leaving ok_to_ignore_lock
permanently true, potentially breaking the device's falling threshold
interrupt detection.

Assign -ETIMEDOUT to the return variable and jump to the error label
to ensure ok_to_ignore_lock is properly reset.

Fixes: 26d90b559057 ("iio: light: opt3001: Fixed timeout error when 0 lux")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260525-opt3001-cleanup-v4-0-65b36a174f78%40gmail.com?part=1
Cc: stable@vger.kernel.org
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
---
 drivers/iio/light/opt3001.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/light/opt3001.c b/drivers/iio/light/opt3001.c
index 03c7a87b4a8eef13bbdcf48dcaf969781aa76bd1..0743e16f2a8fa0f07acd19c7dd6b54bec9e5c7b2 100644
--- a/drivers/iio/light/opt3001.c
+++ b/drivers/iio/light/opt3001.c
@@ -366,8 +366,10 @@ static int opt3001_get_processed(struct opt3001 *opt, int *val, int *val2)
 		ret = wait_event_timeout(opt->result_ready_queue,
 				opt->result_ready,
 				msecs_to_jiffies(OPT3001_RESULT_READY_LONG));
-		if (ret == 0)
-			return -ETIMEDOUT;
+		if (ret == 0) {
+			ret = -ETIMEDOUT;
+			goto err;
+		}
 	} else {
 		/* Sleep for result ready time */
 		timeout = (opt->int_time == OPT3001_INT_TIME_SHORT) ?

---
base-commit: 0e7dbde323808f28c5220295bfc1c5bc6f08c3f4
change-id: 20260526-fix-early-return-e2f1d3662180

Best regards,
-- 
Joshua Crofts <joshua.crofts1@gmail.com>

On Tue, 26 May 2026 13:15:29 +0200
Joshua Crofts via B4 Relay <devnull+joshua.crofts1.gmail.com@kernel.org> wrote:

> From: Joshua Crofts <joshua.crofts1@gmail.com>
> 
> Currently in the function opt3001_get_processed(), there is a check
> that directly returns -ETIMEDOUT if the conversion IRQ times out,
> completely bypassing the err label, leaving ok_to_ignore_lock
> permanently true, potentially breaking the device's falling threshold
> interrupt detection.
> 
> Assign -ETIMEDOUT to the return variable and jump to the error label
> to ensure ok_to_ignore_lock is properly reset.
> 
> Fixes: 26d90b559057 ("iio: light: opt3001: Fixed timeout error when 0 lux")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260525-opt3001-cleanup-v4-0-65b36a174f78%40gmail.com?part=1
> Cc: stable@vger.kernel.org
> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
The flow in this function is horrendous.  IF you have time would you mind
doing a follow up patch that just breaks it in two. Then have
if (opt->use_irq)
	opt3001_get_processed_irq();
else
	opt3001_get_processed_noirq();

Maybe there is some code at the end that is worth sharing - you'll have to have
a play to see if that is worth doing.

(If this was in your other patch set already then I'll blame lack of coffee!)

Applied this to the fixes-togreg branch of iio.git and marked for stable.

Jonathan



> ---
>  drivers/iio/light/opt3001.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/light/opt3001.c b/drivers/iio/light/opt3001.c
> index 03c7a87b4a8eef13bbdcf48dcaf969781aa76bd1..0743e16f2a8fa0f07acd19c7dd6b54bec9e5c7b2 100644
> --- a/drivers/iio/light/opt3001.c
> +++ b/drivers/iio/light/opt3001.c
> @@ -366,8 +366,10 @@ static int opt3001_get_processed(struct opt3001 *opt, int *val, int *val2)
>  		ret = wait_event_timeout(opt->result_ready_queue,
>  				opt->result_ready,
>  				msecs_to_jiffies(OPT3001_RESULT_READY_LONG));
> -		if (ret == 0)
> -			return -ETIMEDOUT;
> +		if (ret == 0) {
> +			ret = -ETIMEDOUT;
> +			goto err;
> +		}
>  	} else {
>  		/* Sleep for result ready time */
>  		timeout = (opt->int_time == OPT3001_INT_TIME_SHORT) ?
> 
> ---
> base-commit: 0e7dbde323808f28c5220295bfc1c5bc6f08c3f4
> change-id: 20260526-fix-early-return-e2f1d3662180
> 
> Best regards,

On Wed, 27 May 2026 at 13:12, Jonathan Cameron <jic23@kernel.org> wrote:
> The flow in this function is horrendous.  IF you have time would you mind
> doing a follow up patch that just breaks it in two. Then have
> if (opt->use_irq)
>         opt3001_get_processed_irq();
> else
>         opt3001_get_processed_noirq();
>
> Maybe there is some code at the end that is worth sharing - you'll have to have
> a play to see if that is worth doing.
>
> (If this was in your other patch set already then I'll blame lack of coffee!)

No, didn't touch on this in the original set unfortunately, but I keep
discovering
all sorts of strange things in this driver. IMO this warranted a quick
solo patch
as it can potentially mess up subsequent reads. I'll probably end up adding
the breakdown in the other series though.

-- 
Kind regards

CJD