[PATCH 00/15] IIO: a bunch of llm-found fixes

[PATCH 00/15] IIO: a bunch of llm-found fixes

[Greg Kroah-Hartman]

Here's a series of some small llm-found fixes that have been sent to me
recently.  Most of them are just minor bugfixes and locking cleanups,
but they are good to have from what I can tell.

Submitting them here to get a solid Sashiko run.  If they seem sane, and
you want me to take these directly through my char-misc tree I can do
that now, or I can gladly wait for you to resend them if you wish to do
that instead.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Josef Bacik (15):
      iio: buffer: let the block keep its DMA fence
      iio: trigger: fail the attach if no sub-IRQ is left
      iio: accel: adxl367: don't stay in standby on -EINVAL
      iio: accel: adxl380: don't stay in standby on -EINVAL
      iio: adc: check the result of ad_sd_init()
      iio: adc: ad7923: add the AD7927 to the SPI ID table
      iio: addac: ad74413r: fix the values of set_multiple
      iio: light: apds9306: push events to the IIO device
      iio: light: tsl2591: don't divide by zero in the dark
      iio: light: tsl2591: don't divide by zero with low gain
      iio: hid-sensors: fix a division by zero
      iio: imu: inv_mpu6050: don't disable the IRQ under lock
      iio: proximity: sx9500: hand on probe deferral of GPIOs
      iio: scmi: use 64-bit divisions for rates and intervals
      iio: sx9310: use the data of the I2C table

 drivers/iio/accel/adxl367.c                           | 11 ++++++++++-
 drivers/iio/accel/adxl380.c                           | 11 ++++++++++-
 drivers/iio/adc/ad7780.c                              |  4 +++-
 drivers/iio/adc/ad7791.c                              |  4 +++-
 drivers/iio/adc/ad7793.c                              |  4 +++-
 drivers/iio/adc/ad7923.c                              |  1 +
 drivers/iio/adc/max11205.c                            |  4 +++-
 drivers/iio/addac/ad74413r.c                          |  2 +-
 .../iio/common/hid-sensors/hid-sensor-attributes.c    |  5 ++++-
 drivers/iio/common/scmi_sensors/scmi_iio.c            | 12 ++++--------
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c            | 19 +++++++++++++++++--
 drivers/iio/industrialio-buffer.c                     | 15 +++++++--------
 drivers/iio/industrialio-trigger.c                    |  1 +
 drivers/iio/light/apds9306.c                          |  2 +-
 drivers/iio/light/tsl2591.c                           | 17 +++++++++++++++--
 drivers/iio/proximity/sx9310.c                        |  2 +-
 drivers/iio/proximity/sx9500.c                        | 16 ++++++++++++----
 17 files changed, 96 insertions(+), 34 deletions(-)
---
base-commit: d135ab453a7400a34930bdda1ef4bdc8acfac80e
change-id: 20261027-llm-char-misc-iio-b845d92b935a

Best regards,
--  
Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[PATCH 01/15] iio: buffer: let the block keep its DMA fence

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

iio_buffer_enqueue_dmabuf() hands a plain pointer to the fence to the
buffer implementation, which keeps it in block->fence, and since the fix
for the fence leak it drops the initial reference right after
dma_resv_add_fence(). The only reference left is the one of the
reservation object.

That one does not last until the fence is signalled. dma_resv_add_fence()
replaces and puts a fence as soon as a later fence of the same context and
the same usage is added. All the fences of an attachment share a context,
and an enqueue on an output buffer only waits for the writers, not for the
read fence of the enqueue before it. A second IIO_BUFFER_DMABUF_ENQUEUE of
a buffer which is still queued is refused by iio_dma_can_enqueue_block(),
but by then its fence has taken the place of the first one. When the DMA
is done, iio_buffer_signal_dmabuf_done() signals a fence which has been
freed and schedules the work item in it.

The leak came from the reference which iio_buffer_signal_dmabuf_done()
takes and iio_buffer_cleanup() drops: with it nobody dropped the initial
one. Do not take it, and leave the initial reference to the block until
the cleanup.

Fixes: a09399935508 ("iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf()")
Cc: stable <stable@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: "Benoît Monin" <benoit.monin@bootlin.com>
Cc: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/industrialio-buffer.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
index 4294101810fd..a2386dba497c 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -1931,9 +1931,14 @@ static int iio_buffer_enqueue_dmabuf(struct iio_dev_buffer_pair *ib,
 	if (ret)
 		goto err_queue_unlock;
 
+	/*
+	 * The reservation object takes a reference of its own, and drops it as
+	 * soon as a later fence of this attachment takes the place of this
+	 * one. The initial reference stays with the block, which points to the
+	 * fence until iio_buffer_cleanup() has run.
+	 */
 	dma_resv_add_fence(dmabuf->resv, &fence->base,
 			   dma_to_ram ? DMA_RESV_USAGE_WRITE : DMA_RESV_USAGE_READ);
-	dma_fence_put(&fence->base);
 	dma_resv_unlock(dmabuf->resv);
 
 	cookie = dma_fence_begin_signalling();
@@ -1989,18 +1994,12 @@ void iio_buffer_signal_dmabuf_done(struct dma_fence *fence, int ret)
 		container_of(fence, struct iio_dma_fence, base);
 	bool cookie = dma_fence_begin_signalling();
 
-	/*
-	 * Get a reference to the fence, so that it's not freed as soon as
-	 * it's signaled.
-	 */
-	dma_fence_get(fence);
-
 	fence->error = ret;
 	dma_fence_signal(fence);
 	dma_fence_end_signalling(cookie);
 
 	/*
-	 * The fence will be unref'd in iio_buffer_cleanup.
+	 * The reference of the block will be dropped in iio_buffer_cleanup.
 	 * It can't be done here, as the unref functions might try to lock the
 	 * resv object, which can deadlock.
 	 */

-- 
2.56.0

Re: [PATCH 01/15] iio: buffer: let the block keep its DMA fence

[Nuno Sá]

On Tue, Oct 27, 2026 at 05:19:05PM +0100, Greg Kroah-Hartman wrote:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> iio_buffer_enqueue_dmabuf() hands a plain pointer to the fence to the
> buffer implementation, which keeps it in block->fence, and since the fix
> for the fence leak it drops the initial reference right after
> dma_resv_add_fence(). The only reference left is the one of the
> reservation object.
> 
> That one does not last until the fence is signalled. dma_resv_add_fence()
> replaces and puts a fence as soon as a later fence of the same context and
> the same usage is added. All the fences of an attachment share a context,
> and an enqueue on an output buffer only waits for the writers, not for the
> read fence of the enqueue before it. A second IIO_BUFFER_DMABUF_ENQUEUE of
> a buffer which is still queued is refused by iio_dma_can_enqueue_block(),
> but by then its fence has taken the place of the first one. When the DMA
> is done, iio_buffer_signal_dmabuf_done() signals a fence which has been
> freed and schedules the work item in it.
> 
> The leak came from the reference which iio_buffer_signal_dmabuf_done()
> takes and iio_buffer_cleanup() drops: with it nobody dropped the initial
> one. Do not take it, and leave the initial reference to the block until
> the cleanup.
> 
> Fixes: a09399935508 ("iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf()")
> Cc: stable <stable@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: "Benoît Monin" <benoit.monin@bootlin.com>
> Cc: Paul Cercueil <paul@crapouillou.net>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---

Patch looks good to me! Maybe Paul remembers why all of that refcouting
dance was needed. Like this, it feels more natural:

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

>  drivers/iio/industrialio-buffer.c | 15 +++++++--------
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
> index 4294101810fd..a2386dba497c 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -1931,9 +1931,14 @@ static int iio_buffer_enqueue_dmabuf(struct iio_dev_buffer_pair *ib,
>  	if (ret)
>  		goto err_queue_unlock;
>  
> +	/*
> +	 * The reservation object takes a reference of its own, and drops it as
> +	 * soon as a later fence of this attachment takes the place of this
> +	 * one. The initial reference stays with the block, which points to the
> +	 * fence until iio_buffer_cleanup() has run.
> +	 */
>  	dma_resv_add_fence(dmabuf->resv, &fence->base,
>  			   dma_to_ram ? DMA_RESV_USAGE_WRITE : DMA_RESV_USAGE_READ);
> -	dma_fence_put(&fence->base);
>  	dma_resv_unlock(dmabuf->resv);
>  
>  	cookie = dma_fence_begin_signalling();
> @@ -1989,18 +1994,12 @@ void iio_buffer_signal_dmabuf_done(struct dma_fence *fence, int ret)
>  		container_of(fence, struct iio_dma_fence, base);
>  	bool cookie = dma_fence_begin_signalling();
>  
> -	/*
> -	 * Get a reference to the fence, so that it's not freed as soon as
> -	 * it's signaled.
> -	 */
> -	dma_fence_get(fence);
> -
>  	fence->error = ret;
>  	dma_fence_signal(fence);
>  	dma_fence_end_signalling(cookie);
>  
>  	/*
> -	 * The fence will be unref'd in iio_buffer_cleanup.
> +	 * The reference of the block will be dropped in iio_buffer_cleanup.
>  	 * It can't be done here, as the unref functions might try to lock the
>  	 * resv object, which can deadlock.
>  	 */
> 
> -- 
> 2.56.0
> 

[PATCH 02/15] iio: trigger: fail the attach if no sub-IRQ is left

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

A trigger can serve CONFIG_IIO_CONSUMERS_PER_TRIGGER devices, two by
default.  When one more device is attached, iio_trigger_get_irq() returns
-ENOMEM.  iio_trigger_attach_poll_func() prints an error, drops the module
reference and jumps to its exit, but ret is still 0 there, so it reports
success.

iio_enable_buffers() goes on as if the poll function were attached.  The
write to buffer/enable succeeds, but no sample ever arrives.  When the
buffer is disabled again, iio_trigger_detach_poll_func() undoes an attach
which has not taken place, with -ENOMEM in pf->irq:

 - iio_trigger_put_irq() calls clear_bit() with the bit number
   -ENOMEM - trig->subirq_base, which clears a bit in whatever lies in
   front of trig->pool;
 - if only one of the real consumers is left, the trigger is switched off
   under it;
 - module_put() drops a reference to the driver module which has been
   dropped already.

All it takes is to set the same trigger as current_trigger of three
devices and to enable their buffers.

Return the error.

Fixes: 995438233579 ("iio: Fix error handling in iio_trigger_attach_poll_func")
Cc: stable <stable@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Leonard Crestez <cdleonard@gmail.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/industrialio-trigger.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
index 76926fee0f84..fc4651490d42 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -293,6 +293,7 @@ int iio_trigger_attach_poll_func(struct iio_trigger *trig,
 	if (pf->irq < 0) {
 		pr_err("Could not find an available irq for trigger %s, CONFIG_IIO_CONSUMERS_PER_TRIGGER=%d limit might be exceeded\n",
 			trig->name, CONFIG_IIO_CONSUMERS_PER_TRIGGER);
+		ret = pf->irq;
 		goto out_put_module;
 	}
 

-- 
2.56.0

Re: [PATCH 02/15] iio: trigger: fail the attach if no sub-IRQ is left

[Nuno Sá]

On Tue, Oct 27, 2026 at 05:19:06PM +0100, Greg Kroah-Hartman wrote:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> A trigger can serve CONFIG_IIO_CONSUMERS_PER_TRIGGER devices, two by
> default.  When one more device is attached, iio_trigger_get_irq() returns
> -ENOMEM.  iio_trigger_attach_poll_func() prints an error, drops the module
> reference and jumps to its exit, but ret is still 0 there, so it reports
> success.
> 
> iio_enable_buffers() goes on as if the poll function were attached.  The
> write to buffer/enable succeeds, but no sample ever arrives.  When the
> buffer is disabled again, iio_trigger_detach_poll_func() undoes an attach
> which has not taken place, with -ENOMEM in pf->irq:
> 
>  - iio_trigger_put_irq() calls clear_bit() with the bit number
>    -ENOMEM - trig->subirq_base, which clears a bit in whatever lies in
>    front of trig->pool;
>  - if only one of the real consumers is left, the trigger is switched off
>    under it;
>  - module_put() drops a reference to the driver module which has been
>    dropped already.
> 
> All it takes is to set the same trigger as current_trigger of three
> devices and to enable their buffers.
> 
> Return the error.
> 
> Fixes: 995438233579 ("iio: Fix error handling in iio_trigger_attach_poll_func")
> Cc: stable <stable@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Leonard Crestez <cdleonard@gmail.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---

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

>  drivers/iio/industrialio-trigger.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
> index 76926fee0f84..fc4651490d42 100644
> --- a/drivers/iio/industrialio-trigger.c
> +++ b/drivers/iio/industrialio-trigger.c
> @@ -293,6 +293,7 @@ int iio_trigger_attach_poll_func(struct iio_trigger *trig,
>  	if (pf->irq < 0) {
>  		pr_err("Could not find an available irq for trigger %s, CONFIG_IIO_CONSUMERS_PER_TRIGGER=%d limit might be exceeded\n",
>  			trig->name, CONFIG_IIO_CONSUMERS_PER_TRIGGER);
> +		ret = pf->irq;
>  		goto out_put_module;
>  	}
>  
> 
> -- 
> 2.56.0
> 

[PATCH 03/15] iio: accel: adxl367: don't stay in standby on -EINVAL

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

adxl367_set_act_threshold() puts the sensor into standby, writes the
threshold and switches the measurement on again.  A threshold above 8191 is
refused in between, and the sensor stays in standby: no samples and no
events until the next write that succeeds.

adxl367_set_range() has the same problem and a worse one.  It rescales both
thresholds for the new range, times four from 8 g to 2 g.  If one no longer
fits it returns -EINVAL with the sensor in standby, the new range in the
chip, the old one in st->range and rescaled thresholds in the driver's
state: from the next successful write on the samples are reported with the
wrong scale.

Switch the measurement on again if the threshold is refused.  In
adxl367_set_range() see whether the thresholds fit before anything is
changed.

Fixes: cbab791c5e2a ("iio: accel: add ADXL367 driver")
Cc: stable <stable@kernel.org>
Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
Cc: Antoniu Miclaus <antoniu.miclaus@analog.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: David Lechner <dlechner@baylibre.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Cosmin Tanislav <demonsingur@gmail.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/accel/adxl367.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/accel/adxl367.c b/drivers/iio/accel/adxl367.c
index 026db73057c5..ba6e7423978f 100644
--- a/drivers/iio/accel/adxl367.c
+++ b/drivers/iio/accel/adxl367.c
@@ -349,8 +349,11 @@ static int adxl367_set_act_threshold(struct adxl367_state *st,
 		return ret;
 
 	ret = _adxl367_set_act_threshold(st, act, threshold);
-	if (ret)
+	if (ret) {
+		/* Leave standby also if the value was refused */
+		adxl367_set_measure_en(st, true);
 		return ret;
+	}
 
 	return adxl367_set_measure_en(st, true);
 }
@@ -483,6 +486,12 @@ static int adxl367_set_range(struct iio_dev *indio_dev,
 
 	guard(mutex)(&st->lock);
 
+	/* The thresholds are rescaled: see that they fit before any change */
+	if (max(st->act_threshold, st->inact_threshold) *
+	    adxl367_range_scale_factor_tbl[st->range] /
+	    adxl367_range_scale_factor_tbl[range] > ADXL367_THRESH_MAX)
+		return -EINVAL;
+
 	ret = adxl367_set_measure_en(st, false);
 	if (ret)
 		return ret;

-- 
2.56.0

Re: [PATCH 03/15] iio: accel: adxl367: don't stay in standby on -EINVAL

[Nuno Sá]

On Tue, Oct 27, 2026 at 05:19:07PM +0100, Greg Kroah-Hartman wrote:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> adxl367_set_act_threshold() puts the sensor into standby, writes the
> threshold and switches the measurement on again.  A threshold above 8191 is
> refused in between, and the sensor stays in standby: no samples and no
> events until the next write that succeeds.
> 
> adxl367_set_range() has the same problem and a worse one.  It rescales both
> thresholds for the new range, times four from 8 g to 2 g.  If one no longer
> fits it returns -EINVAL with the sensor in standby, the new range in the
> chip, the old one in st->range and rescaled thresholds in the driver's
> state: from the next successful write on the samples are reported with the
> wrong scale.
> 
> Switch the measurement on again if the threshold is refused.  In
> adxl367_set_range() see whether the thresholds fit before anything is
> changed.
> 
> Fixes: cbab791c5e2a ("iio: accel: add ADXL367 driver")
> Cc: stable <stable@kernel.org>
> Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
> Cc: Antoniu Miclaus <antoniu.miclaus@analog.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Cosmin Tanislav <demonsingur@gmail.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---

Why don't we use mul_frac() as in the next patch? Also don't love the
condition duplication (feels like some refactor would be worth it). But
for backporting purposes, seems reasonable like. With mul_frac()

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

>  drivers/iio/accel/adxl367.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/adxl367.c b/drivers/iio/accel/adxl367.c
> index 026db73057c5..ba6e7423978f 100644
> --- a/drivers/iio/accel/adxl367.c
> +++ b/drivers/iio/accel/adxl367.c
> @@ -349,8 +349,11 @@ static int adxl367_set_act_threshold(struct adxl367_state *st,
>  		return ret;
>  
>  	ret = _adxl367_set_act_threshold(st, act, threshold);
> -	if (ret)
> +	if (ret) {
> +		/* Leave standby also if the value was refused */
> +		adxl367_set_measure_en(st, true);
>  		return ret;
> +	}
>  
>  	return adxl367_set_measure_en(st, true);
>  }
> @@ -483,6 +486,12 @@ static int adxl367_set_range(struct iio_dev *indio_dev,
>  
>  	guard(mutex)(&st->lock);
>  
> +	/* The thresholds are rescaled: see that they fit before any change */
> +	if (max(st->act_threshold, st->inact_threshold) *
> +	    adxl367_range_scale_factor_tbl[st->range] /
> +	    adxl367_range_scale_factor_tbl[range] > ADXL367_THRESH_MAX)
> +		return -EINVAL;
> +
>  	ret = adxl367_set_measure_en(st, false);
>  	if (ret)
>  		return ret;
> 
> -- 
> 2.56.0
> 

[PATCH 04/15] iio: accel: adxl380: don't stay in standby on -EINVAL

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

adxl380_set_act_inact_threshold() puts the sensor into standby, writes the
threshold and switches the measurement on again.  A threshold above 8191 is
refused in between, and the sensor stays in standby: no samples and no
events until the next write that succeeds.

adxl380_set_range() has the same problem and a worse one.  It rescales both
thresholds for the new range.  If one no longer fits it returns -EINVAL
with the sensor in standby, the new range in the chip, the old one in
st->range and rescaled thresholds in the driver's state: from the next
successful write on the samples are reported with the wrong scale.

Switch the measurement on again if the threshold is refused.  In
adxl380_set_range() see whether the thresholds fit before anything is
changed.

Fixes: df36de13677a ("iio: accel: add ADXL380 driver")
Cc: stable <stable@kernel.org>
Cc: Ramona Gradinariu <ramona.gradinariu@analog.com>
Cc: Antoniu Miclaus <antoniu.miclaus@analog.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: David Lechner <dlechner@baylibre.com>
Cc: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/accel/adxl380.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
index 8518ee23e114..03b140303520 100644
--- a/drivers/iio/accel/adxl380.c
+++ b/drivers/iio/accel/adxl380.c
@@ -334,8 +334,11 @@ static int adxl380_set_act_inact_threshold(struct iio_dev *indio_dev,
 		return ret;
 
 	ret = adxl380_write_act_inact_threshold(st, act, th);
-	if (ret)
+	if (ret) {
+		/* Leave standby also if the value was refused */
+		adxl380_set_measure_en(st, true);
 		return ret;
+	}
 
 	return adxl380_set_measure_en(st, true);
 }
@@ -698,6 +701,12 @@ static int adxl380_set_range(struct adxl380_state *st, u8 range)
 
 	guard(mutex)(&st->lock);
 
+	/* The thresholds are rescaled: see that they fit before any change */
+	if (mult_frac(max(st->act_threshold, st->inact_threshold),
+		      adxl380_range_scale_factor_tbl[st->range],
+		      adxl380_range_scale_factor_tbl[range]) > ADXL380_THRESH_MAX)
+		return -EINVAL;
+
 	ret = adxl380_set_measure_en(st, false);
 	if (ret)
 		return ret;

-- 
2.56.0

Re: [PATCH 04/15] iio: accel: adxl380: don't stay in standby on -EINVAL

[Nuno Sá]

On Tue, Oct 27, 2026 at 05:19:08PM +0100, Greg Kroah-Hartman wrote:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> adxl380_set_act_inact_threshold() puts the sensor into standby, writes the
> threshold and switches the measurement on again.  A threshold above 8191 is
> refused in between, and the sensor stays in standby: no samples and no
> events until the next write that succeeds.
> 
> adxl380_set_range() has the same problem and a worse one.  It rescales both
> thresholds for the new range.  If one no longer fits it returns -EINVAL
> with the sensor in standby, the new range in the chip, the old one in
> st->range and rescaled thresholds in the driver's state: from the next
> successful write on the samples are reported with the wrong scale.
> 
> Switch the measurement on again if the threshold is refused.  In
> adxl380_set_range() see whether the thresholds fit before anything is
> changed.
> 
> Fixes: df36de13677a ("iio: accel: add ADXL380 driver")
> Cc: stable <stable@kernel.org>
> Cc: Ramona Gradinariu <ramona.gradinariu@analog.com>
> Cc: Antoniu Miclaus <antoniu.miclaus@analog.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---

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

>  drivers/iio/accel/adxl380.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
> index 8518ee23e114..03b140303520 100644
> --- a/drivers/iio/accel/adxl380.c
> +++ b/drivers/iio/accel/adxl380.c
> @@ -334,8 +334,11 @@ static int adxl380_set_act_inact_threshold(struct iio_dev *indio_dev,
>  		return ret;
>  
>  	ret = adxl380_write_act_inact_threshold(st, act, th);
> -	if (ret)
> +	if (ret) {
> +		/* Leave standby also if the value was refused */
> +		adxl380_set_measure_en(st, true);
>  		return ret;
> +	}
>  
>  	return adxl380_set_measure_en(st, true);
>  }
> @@ -698,6 +701,12 @@ static int adxl380_set_range(struct adxl380_state *st, u8 range)
>  
>  	guard(mutex)(&st->lock);
>  
> +	/* The thresholds are rescaled: see that they fit before any change */
> +	if (mult_frac(max(st->act_threshold, st->inact_threshold),
> +		      adxl380_range_scale_factor_tbl[st->range],
> +		      adxl380_range_scale_factor_tbl[range]) > ADXL380_THRESH_MAX)
> +		return -EINVAL;
> +
>  	ret = adxl380_set_measure_en(st, false);
>  	if (ret)
>  		return ret;
> 
> -- 
> 2.56.0
> 

[PATCH 05/15] iio: adc: check the result of ad_sd_init()

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

ad_sd_init() asks for the optional "rdy" GPIO and returns the error if
that fails, for instance -EPROBE_DEFER. The binding of the AD7780
describes such a GPIO.

ad7780, ad7791, ad7793 and max11205 ignore the result. The function has
then returned before it set the driver data of the IIO device, which
devm_ad_sd_setup_buffer_and_trigger() dereferences a few lines further
down in these probe functions, and sigma_delta->rdy_gpiod holds an
ERR_PTR() which ad_sigma_delta_clear_pending_event() takes for a GPIO.

Return the error, as the other users of the library do.

Fixes: a87ef09b1fdf ("iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO")
Cc: stable <stable@kernel.org>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Renato Lui Geh <renatogeh@gmail.com>
Cc: David Lechner <dlechner@baylibre.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Ramona Bolboaca <ramona.bolboaca@analog.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/adc/ad7780.c   | 4 +++-
 drivers/iio/adc/ad7791.c   | 4 +++-
 drivers/iio/adc/ad7793.c   | 4 +++-
 drivers/iio/adc/max11205.c | 4 +++-
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/adc/ad7780.c b/drivers/iio/adc/ad7780.c
index 1cfad70320fe..c1428f30241c 100644
--- a/drivers/iio/adc/ad7780.c
+++ b/drivers/iio/adc/ad7780.c
@@ -311,7 +311,9 @@ static int ad7780_probe(struct spi_device *spi)
 	st = iio_priv(indio_dev);
 	st->gain = 1;
 
-	ad_sd_init(&st->sd, indio_dev, spi, &ad7780_sigma_delta_info);
+	ret = ad_sd_init(&st->sd, indio_dev, spi, &ad7780_sigma_delta_info);
+	if (ret)
+		return ret;
 
 	st->chip_info =
 		&ad7780_chip_info_tbl[spi_get_device_id(spi)->driver_data];
diff --git a/drivers/iio/adc/ad7791.c b/drivers/iio/adc/ad7791.c
index c2688307bbba..10aa40ca35e7 100644
--- a/drivers/iio/adc/ad7791.c
+++ b/drivers/iio/adc/ad7791.c
@@ -435,7 +435,9 @@ static int ad7791_probe(struct spi_device *spi)
 		return ret;
 
 	st->info = &ad7791_chip_infos[spi_get_device_id(spi)->driver_data];
-	ad_sd_init(&st->sd, indio_dev, spi, &ad7791_sigma_delta_info);
+	ret = ad_sd_init(&st->sd, indio_dev, spi, &ad7791_sigma_delta_info);
+	if (ret)
+		return ret;
 
 	indio_dev->name = spi_get_device_id(spi)->name;
 	indio_dev->modes = INDIO_DIRECT_MODE;
diff --git a/drivers/iio/adc/ad7793.c b/drivers/iio/adc/ad7793.c
index b0f44c144f20..937c8b09ad45 100644
--- a/drivers/iio/adc/ad7793.c
+++ b/drivers/iio/adc/ad7793.c
@@ -796,7 +796,9 @@ static int ad7793_probe(struct spi_device *spi)
 
 	st = iio_priv(indio_dev);
 
-	ad_sd_init(&st->sd, indio_dev, spi, &ad7793_sigma_delta_info);
+	ret = ad_sd_init(&st->sd, indio_dev, spi, &ad7793_sigma_delta_info);
+	if (ret)
+		return ret;
 
 	if (pdata->refsel != AD7793_REFSEL_INTERNAL) {
 		ret = devm_regulator_get_enable_read_voltage(dev, "refin");
diff --git a/drivers/iio/adc/max11205.c b/drivers/iio/adc/max11205.c
index 53ac2f4f383e..e46e90400bdc 100644
--- a/drivers/iio/adc/max11205.c
+++ b/drivers/iio/adc/max11205.c
@@ -114,7 +114,9 @@ static int max11205_probe(struct spi_device *spi)
 
 	st = iio_priv(indio_dev);
 
-	ad_sd_init(&st->sd, indio_dev, spi, &max11205_sigma_delta_info);
+	ret = ad_sd_init(&st->sd, indio_dev, spi, &max11205_sigma_delta_info);
+	if (ret)
+		return ret;
 
 	st->chip_info = spi_get_device_match_data(spi);
 	if (!st->chip_info)

-- 
2.56.0

Re: [PATCH 05/15] iio: adc: check the result of ad_sd_init()

[Nuno Sá]

On Tue, Oct 27, 2026 at 05:19:09PM +0100, Greg Kroah-Hartman wrote:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> ad_sd_init() asks for the optional "rdy" GPIO and returns the error if
> that fails, for instance -EPROBE_DEFER. The binding of the AD7780
> describes such a GPIO.
> 
> ad7780, ad7791, ad7793 and max11205 ignore the result. The function has
> then returned before it set the driver data of the IIO device, which
> devm_ad_sd_setup_buffer_and_trigger() dereferences a few lines further
> down in these probe functions, and sigma_delta->rdy_gpiod holds an
> ERR_PTR() which ad_sigma_delta_clear_pending_event() takes for a GPIO.
> 
> Return the error, as the other users of the library do.
> 
> Fixes: a87ef09b1fdf ("iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO")
> Cc: stable <stable@kernel.org>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> Cc: Renato Lui Geh <renatogeh@gmail.com>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Ramona Bolboaca <ramona.bolboaca@analog.com>
> Cc: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---

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

>  drivers/iio/adc/ad7780.c   | 4 +++-
>  drivers/iio/adc/ad7791.c   | 4 +++-
>  drivers/iio/adc/ad7793.c   | 4 +++-
>  drivers/iio/adc/max11205.c | 4 +++-
>  4 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad7780.c b/drivers/iio/adc/ad7780.c
> index 1cfad70320fe..c1428f30241c 100644
> --- a/drivers/iio/adc/ad7780.c
> +++ b/drivers/iio/adc/ad7780.c
> @@ -311,7 +311,9 @@ static int ad7780_probe(struct spi_device *spi)
>  	st = iio_priv(indio_dev);
>  	st->gain = 1;
>  
> -	ad_sd_init(&st->sd, indio_dev, spi, &ad7780_sigma_delta_info);
> +	ret = ad_sd_init(&st->sd, indio_dev, spi, &ad7780_sigma_delta_info);
> +	if (ret)
> +		return ret;
>  
>  	st->chip_info =
>  		&ad7780_chip_info_tbl[spi_get_device_id(spi)->driver_data];
> diff --git a/drivers/iio/adc/ad7791.c b/drivers/iio/adc/ad7791.c
> index c2688307bbba..10aa40ca35e7 100644
> --- a/drivers/iio/adc/ad7791.c
> +++ b/drivers/iio/adc/ad7791.c
> @@ -435,7 +435,9 @@ static int ad7791_probe(struct spi_device *spi)
>  		return ret;
>  
>  	st->info = &ad7791_chip_infos[spi_get_device_id(spi)->driver_data];
> -	ad_sd_init(&st->sd, indio_dev, spi, &ad7791_sigma_delta_info);
> +	ret = ad_sd_init(&st->sd, indio_dev, spi, &ad7791_sigma_delta_info);
> +	if (ret)
> +		return ret;
>  
>  	indio_dev->name = spi_get_device_id(spi)->name;
>  	indio_dev->modes = INDIO_DIRECT_MODE;
> diff --git a/drivers/iio/adc/ad7793.c b/drivers/iio/adc/ad7793.c
> index b0f44c144f20..937c8b09ad45 100644
> --- a/drivers/iio/adc/ad7793.c
> +++ b/drivers/iio/adc/ad7793.c
> @@ -796,7 +796,9 @@ static int ad7793_probe(struct spi_device *spi)
>  
>  	st = iio_priv(indio_dev);
>  
> -	ad_sd_init(&st->sd, indio_dev, spi, &ad7793_sigma_delta_info);
> +	ret = ad_sd_init(&st->sd, indio_dev, spi, &ad7793_sigma_delta_info);
> +	if (ret)
> +		return ret;
>  
>  	if (pdata->refsel != AD7793_REFSEL_INTERNAL) {
>  		ret = devm_regulator_get_enable_read_voltage(dev, "refin");
> diff --git a/drivers/iio/adc/max11205.c b/drivers/iio/adc/max11205.c
> index 53ac2f4f383e..e46e90400bdc 100644
> --- a/drivers/iio/adc/max11205.c
> +++ b/drivers/iio/adc/max11205.c
> @@ -114,7 +114,9 @@ static int max11205_probe(struct spi_device *spi)
>  
>  	st = iio_priv(indio_dev);
>  
> -	ad_sd_init(&st->sd, indio_dev, spi, &max11205_sigma_delta_info);
> +	ret = ad_sd_init(&st->sd, indio_dev, spi, &max11205_sigma_delta_info);
> +	if (ret)
> +		return ret;
>  
>  	st->chip_info = spi_get_device_match_data(spi);
>  	if (!st->chip_info)
> 
> -- 
> 2.56.0
> 

[PATCH 06/15] iio: adc: ad7923: add the AD7927 to the SPI ID table

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

The binding describes the AD7927 as

  compatible = "adi,ad7927", "adi,ad7928";

The OF match takes the second string. The modalias of the SPI device is
made from the first one, "ad7927", which is not in the spi_device_id table:
spi_get_device_id() returns NULL and ad7923_probe() dereferences it for
the chip information. The module is not loaded automatically either, as the
uevent of an SPI device says "spi:ad7927".

Add the name, with the data of the AD7928.

Fixes: 1140f96cd4af ("dt-bindings: iio: adc: ad7923: adjust documentation")
Cc: stable <stable@kernel.org>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: David Lechner <dlechner@baylibre.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Edmund Berenson <edmund.berenson@emlix.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/adc/ad7923.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/adc/ad7923.c b/drivers/iio/adc/ad7923.c
index 44e014da9722..69fafb4aa4ea 100644
--- a/drivers/iio/adc/ad7923.c
+++ b/drivers/iio/adc/ad7923.c
@@ -366,6 +366,7 @@ static const struct spi_device_id ad7923_id[] = {
 	{ .name = "ad7924", .driver_data = AD7924 },
 	{ .name = "ad7908", .driver_data = AD7908 },
 	{ .name = "ad7918", .driver_data = AD7918 },
+	{ .name = "ad7927", .driver_data = AD7928 },
 	{ .name = "ad7928", .driver_data = AD7928 },
 	{ }
 };

-- 
2.56.0

Re: [PATCH 06/15] iio: adc: ad7923: add the AD7927 to the SPI ID table

[Nuno Sá]

On Tue, Oct 27, 2026 at 05:19:10PM +0100, Greg Kroah-Hartman wrote:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> The binding describes the AD7927 as
> 
>   compatible = "adi,ad7927", "adi,ad7928";
> 
> The OF match takes the second string. The modalias of the SPI device is
> made from the first one, "ad7927", which is not in the spi_device_id table:
> spi_get_device_id() returns NULL and ad7923_probe() dereferences it for
> the chip information. The module is not loaded automatically either, as the
> uevent of an SPI device says "spi:ad7927".
> 
> Add the name, with the data of the AD7928.
> 
> Fixes: 1140f96cd4af ("dt-bindings: iio: adc: ad7923: adjust documentation")
> Cc: stable <stable@kernel.org>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Edmund Berenson <edmund.berenson@emlix.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---

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

>  drivers/iio/adc/ad7923.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iio/adc/ad7923.c b/drivers/iio/adc/ad7923.c
> index 44e014da9722..69fafb4aa4ea 100644
> --- a/drivers/iio/adc/ad7923.c
> +++ b/drivers/iio/adc/ad7923.c
> @@ -366,6 +366,7 @@ static const struct spi_device_id ad7923_id[] = {
>  	{ .name = "ad7924", .driver_data = AD7924 },
>  	{ .name = "ad7908", .driver_data = AD7908 },
>  	{ .name = "ad7918", .driver_data = AD7918 },
> +	{ .name = "ad7927", .driver_data = AD7928 },
>  	{ .name = "ad7928", .driver_data = AD7928 },
>  	{ }
>  };
> 
> -- 
> 2.56.0
> 

[PATCH 07/15] iio: addac: ad74413r: fix the values of set_multiple

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

ad74413r_gpio_set_multiple() walks over the lines in the mask and looks up
the new value of each with

	if (*bits & offset)

offset is the number of the line, not a bit mask.  Line 0 is always driven
low, line 1 gets the value meant for line 0, line 2 the one meant for line
1, and line 3 is driven high if either of these two is.

Test the bit which belongs to the line.

Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
Cc: stable <stable@kernel.org>
Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
Cc: Antoniu Miclaus <antoniu.miclaus@analog.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: David Lechner <dlechner@baylibre.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Linus Walleij <linusw@kernel.org>
Cc: Bartosz Golaszewski <brgl@kernel.org>
Cc: Cosmin Tanislav <demonsingur@gmail.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/addac/ad74413r.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/addac/ad74413r.c b/drivers/iio/addac/ad74413r.c
index 2e5a58e48a89..20db890d958b 100644
--- a/drivers/iio/addac/ad74413r.c
+++ b/drivers/iio/addac/ad74413r.c
@@ -312,7 +312,7 @@ static int ad74413r_gpio_set_multiple(struct gpio_chip *chip,
 			return ret;
 
 		real_mask |= BIT(real_offset);
-		if (*bits & offset)
+		if (test_bit(offset, bits))
 			real_bits |= BIT(real_offset);
 	}
 

-- 
2.56.0

Re: [PATCH 07/15] iio: addac: ad74413r: fix the values of set_multiple

[Nuno Sá]

On Tue, Oct 27, 2026 at 05:19:11PM +0100, Greg Kroah-Hartman wrote:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> ad74413r_gpio_set_multiple() walks over the lines in the mask and looks up
> the new value of each with
> 
> 	if (*bits & offset)
> 
> offset is the number of the line, not a bit mask.  Line 0 is always driven
> low, line 1 gets the value meant for line 0, line 2 the one meant for line
> 1, and line 3 is driven high if either of these two is.
> 
> Test the bit which belongs to the line.
> 
> Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
> Cc: stable <stable@kernel.org>
> Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
> Cc: Antoniu Miclaus <antoniu.miclaus@analog.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Linus Walleij <linusw@kernel.org>
> Cc: Bartosz Golaszewski <brgl@kernel.org>
> Cc: Cosmin Tanislav <demonsingur@gmail.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---

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

>  drivers/iio/addac/ad74413r.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/addac/ad74413r.c b/drivers/iio/addac/ad74413r.c
> index 2e5a58e48a89..20db890d958b 100644
> --- a/drivers/iio/addac/ad74413r.c
> +++ b/drivers/iio/addac/ad74413r.c
> @@ -312,7 +312,7 @@ static int ad74413r_gpio_set_multiple(struct gpio_chip *chip,
>  			return ret;
>  
>  		real_mask |= BIT(real_offset);
> -		if (*bits & offset)
> +		if (test_bit(offset, bits))
>  			real_bits |= BIT(real_offset);
>  	}
>  
> 
> -- 
> 2.56.0
> 

[PATCH 08/15] iio: light: apds9306: push events to the IIO device

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

Reading a light channel while threshold events are enabled can push an
event through a pointer that is not an IIO device, corrupting memory or
crashing the kernel.

apds9306_read_data() derives indio_dev with dev_to_iio_dev(data->dev),
but data->dev is the I2C client's device, not the device embedded in
struct iio_dev. When the status register read by the poll loop has
APDS9306_ALS_INT_STAT_MASK set, the bogus pointer is passed to
iio_push_event() and iio_get_time_ns(), which dereference the event
interface and clock id of a structure that does not exist.

The bug was found by code inspection and has not been reproduced.

Fix by taking the IIO device from the I2C client's driver data, which
probe sets with i2c_set_clientdata().

Fixes: 620d1e6c7a3f ("iio: light: Add support for APDS9306 Light Sensor")
Cc: stable <stable@kernel.org>
Cc: Subhajit Ghosh <subhajit.ghosh@tweaklogic.com>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/light/apds9306.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/light/apds9306.c b/drivers/iio/light/apds9306.c
index 7dd41136734f..79138422221d 100644
--- a/drivers/iio/light/apds9306.c
+++ b/drivers/iio/light/apds9306.c
@@ -462,7 +462,7 @@ static int apds9306_power_state(struct apds9306_data *data, bool state)
 static int apds9306_read_data(struct apds9306_data *data, int *val, int reg)
 {
 	struct device *dev = data->dev;
-	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
 	struct apds9306_regfields *rf = &data->rf;
 	u64 ev_code;
 	int ret, delay, intg_time, intg_time_idx, repeat_rate_idx, int_src;

-- 
2.56.0

[PATCH 09/15] iio: light: tsl2591: don't divide by zero in the dark

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

The computation of the illuminance divides by the count of channel 0.
That is the channel which sees the whole spectrum: in complete darkness it
reads zero, and reading in_illuminance_input divides by zero.  Depending
on the architecture this is an oops, a warning with a backtrace, or goes
unnoticed.

Report 0 lux in that case.

Fixes: 2335f0d7c790 ("iio: light: Added AMS tsl2591 driver implementation")
Cc: stable <stable@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Matheus Silveira <matheus.feitosa@usp.br>
Cc: Lucas Rabaquim <lucas.rabaquim@usp.br>
Cc: Stepan Ionichev <sozdayvek@gmail.com>
Cc: Joe Sandom <joe.g.sandom@gmail.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/light/tsl2591.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iio/light/tsl2591.c b/drivers/iio/light/tsl2591.c
index ef3ed9635a1e..286dc09e170f 100644
--- a/drivers/iio/light/tsl2591.c
+++ b/drivers/iio/light/tsl2591.c
@@ -416,6 +416,13 @@ static int tsl2591_read_channel_data(struct iio_dev *indio_dev,
 
 		dev_dbg(&client->dev, "Counts Per Lux: %d\n", counts_per_lux);
 
+		/* No light at all: the formula below divides by als_ch0 */
+		if (!als_ch0) {
+			*val = 0;
+			*val2 = 0;
+			break;
+		}
+
 		/* Calculate lux value */
 		lux = ((als_ch0 - als_ch1) *
 		       (1000 - ((als_ch1 * 1000) / als_ch0))) / counts_per_lux;

-- 
2.56.0

[PATCH 10/15] iio: light: tsl2591: don't divide by zero with low gain

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

The number of counts per lux is the integration time in milliseconds times
the gain, divided by 408.  With the low gain, which is 1, and an
integration time of 100 to 400 ms, that is 0 in integer arithmetic, and
each read of the illuminance divides by zero.

In that case, multiply by the coefficient and divide by the product
instead.  The result of the other settings does not change.

Fixes: 2335f0d7c790 ("iio: light: Added AMS tsl2591 driver implementation")
Cc: stable <stable@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lucas Rabaquim <lucas.rabaquim@usp.br>
Cc: Matheus Silveira <matheus.feitosa@usp.br>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Stepan Ionichev <sozdayvek@gmail.com>
Cc: Joe Sandom <joe.g.sandom@gmail.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/light/tsl2591.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/light/tsl2591.c b/drivers/iio/light/tsl2591.c
index 286dc09e170f..773b50c17e71 100644
--- a/drivers/iio/light/tsl2591.c
+++ b/drivers/iio/light/tsl2591.c
@@ -16,6 +16,7 @@
 #include <linux/interrupt.h>
 #include <linux/iopoll.h>
 #include <linux/kernel.h>
+#include <linux/math64.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
 #include <linux/pm_runtime.h>
@@ -424,8 +425,13 @@ static int tsl2591_read_channel_data(struct iio_dev *indio_dev,
 		}
 
 		/* Calculate lux value */
-		lux = ((als_ch0 - als_ch1) *
-		       (1000 - ((als_ch1 * 1000) / als_ch0))) / counts_per_lux;
+		lux = (als_ch0 - als_ch1) *
+		      (1000 - ((als_ch1 * 1000) / als_ch0));
+		if (counts_per_lux)
+			lux /= counts_per_lux;
+		else	/* Less than one count per lux */
+			lux = div_s64((s64)lux * TSL2591_LUX_COEFFICIENT,
+				      int_time_fval * gain_multi);
 
 		dev_dbg(&client->dev, "Raw lux calculation: %d\n", lux);
 

-- 
2.56.0

Re: [PATCH 10/15] iio: light: tsl2591: don't divide by zero with low gain

[Jonathan Cameron]

On Tue, 27 Oct 2026 17:19:14 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> From: Josef Bacik <josef@toxicpanda.com>
> 
> The number of counts per lux is the integration time in milliseconds times
> the gain, divided by 408.  With the low gain, which is 1, and an
> integration time of 100 to 400 ms, that is 0 in integer arithmetic, and
> each read of the illuminance divides by zero.
> 
> In that case, multiply by the coefficient and divide by the product
> instead.  The result of the other settings does not change.
> 
https://lore.kernel.org/all/20261022-first-patch-v4-0-90b2fc6e8e28@mycroftmind.com/

I have first few of that series queued up already.

Jonathan


> Fixes: 2335f0d7c790 ("iio: light: Added AMS tsl2591 driver implementation")
> Cc: stable <stable@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Lucas Rabaquim <lucas.rabaquim@usp.br>
> Cc: Matheus Silveira <matheus.feitosa@usp.br>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: Stepan Ionichev <sozdayvek@gmail.com>
> Cc: Joe Sandom <joe.g.sandom@gmail.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/iio/light/tsl2591.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/light/tsl2591.c b/drivers/iio/light/tsl2591.c
> index 286dc09e170f..773b50c17e71 100644
> --- a/drivers/iio/light/tsl2591.c
> +++ b/drivers/iio/light/tsl2591.c
> @@ -16,6 +16,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/iopoll.h>
>  #include <linux/kernel.h>
> +#include <linux/math64.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
>  #include <linux/pm_runtime.h>
> @@ -424,8 +425,13 @@ static int tsl2591_read_channel_data(struct iio_dev *indio_dev,
>  		}
>  
>  		/* Calculate lux value */
> -		lux = ((als_ch0 - als_ch1) *
> -		       (1000 - ((als_ch1 * 1000) / als_ch0))) / counts_per_lux;
> +		lux = (als_ch0 - als_ch1) *
> +		      (1000 - ((als_ch1 * 1000) / als_ch0));
> +		if (counts_per_lux)
> +			lux /= counts_per_lux;
> +		else	/* Less than one count per lux */
> +			lux = div_s64((s64)lux * TSL2591_LUX_COEFFICIENT,
> +				      int_time_fval * gain_multi);
>  
>  		dev_dbg(&client->dev, "Raw lux calculation: %d\n", lux);
>  
> 

Re: [PATCH 10/15] iio: light: tsl2591: don't divide by zero with low gain

[Greg Kroah-Hartman]

On Wed, Oct 28, 2026 at 02:13:02AM +0000, Jonathan Cameron wrote:
> On Tue, 27 Oct 2026 17:19:14 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > From: Josef Bacik <josef@toxicpanda.com>
> > 
> > The number of counts per lux is the integration time in milliseconds times
> > the gain, divided by 408.  With the low gain, which is 1, and an
> > integration time of 100 to 400 ms, that is 0 in integer arithmetic, and
> > each read of the illuminance divides by zero.
> > 
> > In that case, multiply by the coefficient and divide by the product
> > instead.  The result of the other settings does not change.
> > 
> https://lore.kernel.org/all/20261022-first-patch-v4-0-90b2fc6e8e28@mycroftmind.com/
> 
> I have first few of that series queued up already.

Wonderful, thanks!  Proof again that people keep finding the same bugs
at the same time with these tools :)

greg k-h

[PATCH 11/15] iio: hid-sensors: fix a division by zero

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

convert_to_vtf_format() divides the micro part of a value by
10^(6 + exp).  The unit exponent of a HID field is a nibble and goes
down to -8.  For -7 and -8 the argument of int_pow() is negative, which
the unsigned parameter turns into a huge power of ten: 0 modulo 2^64.
The division by it is a divide error.  The exponent comes from the report
descriptor of the sensor hub, the value from a write to the hysteresis
attribute of the IIO device.

Multiply by 10^(-exp - 6) in these two cases.

Fixes: 73c6768b710a ("iio: hid-sensors: Common attribute and trigger")
Cc: stable <stable@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Cc: Shi Hao <i.shihao.999@gmail.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
index 9e7c26e37880..3b0985d500ae 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
@@ -140,7 +140,10 @@ static u32 convert_to_vtf_format(int size, int exp, int val1, int val2)
 	if (val1 < 0 || val2 < 0)
 		sign = -1;
 	exp = hid_sensor_convert_exponent(exp);
-	if (exp < 0) {
+	if (exp < -6) {
+		value = abs(val1) * int_pow(10, -exp);
+		value += abs(val2) * int_pow(10, -exp - 6);
+	} else if (exp < 0) {
 		divisor = int_pow(10, 6 + exp);
 		value = abs(val1) * int_pow(10, -exp);
 		value += abs(val2) / divisor;

-- 
2.56.0

[PATCH 12/15] iio: imu: inv_mpu6050: don't disable the IRQ under lock

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

If the chip is a wake-up source, inv_mpu_suspend() calls disable_irq() with
st->lock held.  disable_irq() waits for the threaded handler, and
inv_mpu6050_interrupt_handle() takes st->lock to read the interrupt
status.  If the chip raises an interrupt while the system is being
suspended, the handler waits for the lock, the suspend callback waits for
the handler, and the suspend hangs.

Disable the interrupt once the lock has been dropped.

Fixes: 305914d01807 ("iio: imu: inv_mpu6050: add WoM suspend wakeup with low-power mode")
Cc: stable <stable@kernel.org>
Cc: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index 38c3f3b398d4..0ae9d497ccfd 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -2166,7 +2166,7 @@ static int inv_mpu_resume(struct device *dev)
 	return result;
 }
 
-static int inv_mpu_suspend(struct device *dev)
+static int __inv_mpu_suspend(struct device *dev, bool *disable)
 {
 	struct iio_dev *indio_dev = dev_get_drvdata(dev);
 	struct inv_mpu6050_state *st = iio_priv(indio_dev);
@@ -2212,7 +2212,7 @@ static int inv_mpu_suspend(struct device *dev)
 		if (result)
 			return result;
 		enable_irq_wake(st->irq);
-		disable_irq(st->irq);
+		*disable = true;
 	} else {
 		result = inv_mpu6050_set_power_itg(st, false);
 		if (result)
@@ -2223,6 +2223,21 @@ static int inv_mpu_suspend(struct device *dev)
 	return 0;
 }
 
+static int inv_mpu_suspend(struct device *dev)
+{
+	struct inv_mpu6050_state *st = iio_priv(dev_get_drvdata(dev));
+	bool disable = false;
+	int result;
+
+	result = __inv_mpu_suspend(dev, &disable);
+
+	/* Not under st->lock: this waits for the handler, which takes it */
+	if (disable)
+		disable_irq(st->irq);
+
+	return result;
+}
+
 static int inv_mpu_runtime_suspend(struct device *dev)
 {
 	struct inv_mpu6050_state *st = iio_priv(dev_get_drvdata(dev));

-- 
2.56.0

[PATCH 13/15] iio: proximity: sx9500: hand on probe deferral of GPIOs

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

sx9500_gpio_probe() treats every failure of devm_gpiod_get() as "the
line does not exist".  If the GPIO controller has not been probed yet,
the lookup fails with -EPROBE_DEFER, and the driver binds for good
without the line:

 - without the "interrupt" GPIO client->irq stays 0, so no interrupt is
   requested and no trigger is registered: the device has no events and
   no data-ready trigger until it is unbound and bound again;
 - without the "reset" GPIO the chip is not reset in
   sx9500_init_device().

Which of the two happens depends only on the order in which the drivers
are probed.  Return -EPROBE_DEFER so that the probe is repeated once the
controller is there.  All other errors are handled as before.  The i2c
core sets client->irq again at the start of every probe, so a deferral
on the second line leaves nothing behind.

A system that describes one of the lines but never gets a driver for its
GPIO controller now keeps the sensor in the deferred list instead of
binding it without the line.

Fixes: 45fd5f8e10d3 ("iio: sx9500: add GPIO reset pin")
Fixes: e53111ad5dea ("iio: proximity: sx9500: Assign interrupt from GpioIo()")
Cc: stable <stable@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
Cc: Siratul Islam <email@sirat.me>
Cc: Vlad Dogaru <ddvlad@gmail.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/proximity/sx9500.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c
index dadce9b44227..94cc577f4404 100644
--- a/drivers/iio/proximity/sx9500.c
+++ b/drivers/iio/proximity/sx9500.c
@@ -853,15 +853,15 @@ static const struct acpi_gpio_mapping acpi_sx9500_gpios[] = {
 	{ }
 };
 
-static void sx9500_gpio_probe(struct i2c_client *client,
-			      struct sx9500_data *data)
+static int sx9500_gpio_probe(struct i2c_client *client,
+			     struct sx9500_data *data)
 {
 	struct gpio_desc *gpiod_int;
 	struct device *dev;
 	int ret;
 
 	if (!client)
-		return;
+		return 0;
 
 	dev = &client->dev;
 
@@ -871,6 +871,8 @@ static void sx9500_gpio_probe(struct i2c_client *client,
 
 	if (client->irq <= 0) {
 		gpiod_int = devm_gpiod_get(dev, "interrupt", GPIOD_IN);
+		if (PTR_ERR(gpiod_int) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 		if (IS_ERR(gpiod_int))
 			dev_err(dev, "gpio get irq failed\n");
 		else
@@ -878,10 +880,14 @@ static void sx9500_gpio_probe(struct i2c_client *client,
 	}
 
 	data->gpiod_rst = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+	if (PTR_ERR(data->gpiod_rst) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
 	if (IS_ERR(data->gpiod_rst)) {
 		dev_warn(dev, "gpio get reset pin failed\n");
 		data->gpiod_rst = NULL;
 	}
+
+	return 0;
 }
 
 static int sx9500_probe(struct i2c_client *client)
@@ -911,7 +917,9 @@ static int sx9500_probe(struct i2c_client *client)
 	indio_dev->modes = INDIO_DIRECT_MODE;
 	i2c_set_clientdata(client, indio_dev);
 
-	sx9500_gpio_probe(client, data);
+	ret = sx9500_gpio_probe(client, data);
+	if (ret)
+		return ret;
 
 	ret = sx9500_init_device(indio_dev);
 	if (ret < 0)

-- 
2.56.0

Re: [PATCH 13/15] iio: proximity: sx9500: hand on probe deferral of GPIOs

[Jonathan Cameron]

On Tue, 27 Oct 2026 17:19:17 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> From: Josef Bacik <josef@toxicpanda.com>
> 
> sx9500_gpio_probe() treats every failure of devm_gpiod_get() as "the
> line does not exist".
>
>  If the GPIO controller has not been probed yet,
> the lookup fails with -EPROBE_DEFER, and the driver binds for good
> without the line:
> 
>  - without the "interrupt" GPIO client->irq stays 0, so no interrupt is
>    requested and no trigger is registered: the device has no events and
>    no data-ready trigger until it is unbound and bound again;
>  - without the "reset" GPIO the chip is not reset in
>    sx9500_init_device().
> 
> Which of the two happens depends only on the order in which the drivers
> are probed.  Return -EPROBE_DEFER so that the probe is repeated once the
> controller is there.  All other errors are handled as before.  The i2c
> core sets client->irq again at the start of every probe, so a deferral
> on the second line leaves nothing behind.
> 
> A system that describes one of the lines but never gets a driver for its
> GPIO controller now keeps the sensor in the deferred list instead of
> binding it without the line.
That's all a bit long winded though accurate.

The original code is rather odd.  If the intent is to actually have
these as optional gpios, why not use devm_gpiod_get_optional()
which documents that intent?

Anyhow, I suggest a bit more radical surgery given the driver
is fine without the irq and the code being fixes smells like it is
papering over ancient firmware. It definitely shouldn't run on
a modern system.

> 
> Fixes: 45fd5f8e10d3 ("iio: sx9500: add GPIO reset pin")
> Fixes: e53111ad5dea ("iio: proximity: sx9500: Assign interrupt from GpioIo()")
> Cc: stable <stable@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
> Cc: Siratul Islam <email@sirat.me>
> Cc: Vlad Dogaru <ddvlad@gmail.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/iio/proximity/sx9500.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c
> index dadce9b44227..94cc577f4404 100644
> --- a/drivers/iio/proximity/sx9500.c
> +++ b/drivers/iio/proximity/sx9500.c
> @@ -853,15 +853,15 @@ static const struct acpi_gpio_mapping acpi_sx9500_gpios[] = {
>  	{ }
>  };
>  
> -static void sx9500_gpio_probe(struct i2c_client *client,
> -			      struct sx9500_data *data)
> +static int sx9500_gpio_probe(struct i2c_client *client,
> +			     struct sx9500_data *data)
>  {
>  	struct gpio_desc *gpiod_int;
>  	struct device *dev;
>  	int ret;
>  
>  	if (!client)
> -		return;
> +		return 0;
>  
>  	dev = &client->dev;
>  
> @@ -871,6 +871,8 @@ static void sx9500_gpio_probe(struct i2c_client *client,
>  
>  	if (client->irq <= 0) {
>  		gpiod_int = devm_gpiod_get(dev, "interrupt", GPIOD_IN);
> +		if (PTR_ERR(gpiod_int) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
>  		if (IS_ERR(gpiod_int))
>  			dev_err(dev, "gpio get irq failed\n");

This is 'novel'. I did some archaeology.  Goes back almost 11 years
and at the time the driver only had ACPI and i2c_device_id. So
assuming we weren't talking board files I suppose this is papering over
a broken ACPI firmware.

Given the driver works fine without the interrupt (despite that print
implying it is an error).
Shall we just rip this out?  The irq from any modern firmware will
be in client->irq anyway so this section doesn't run.

>  		else
> @@ -878,10 +880,14 @@ static void sx9500_gpio_probe(struct i2c_client *client,
>  	}

The next bit is valid, though with the above gone, I'd be tempted
to flatten this helper and just get the gpio inline.

>  
>  	data->gpiod_rst = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);

	data->gpiod_rst = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
	if (PTR_ERR(data->gpiod_rst))
		return dev_err_probe(dev, "gpio get reset failed\n");
	if (!data->gpiod_rst)
		dev_warn(dev, "gpio reset not available\n:);

	return 0;

> +	if (PTR_ERR(data->gpiod_rst) == -EPROBE_DEFER)
> +		return -EPROBE_DEFER;
>  	if (IS_ERR(data->gpiod_rst)) {
>  		dev_warn(dev, "gpio get reset pin failed\n");
>  		data->gpiod_rst = NULL;
>  	}
> +
> +	return 0;
>  }
>  
>  static int sx9500_probe(struct i2c_client *client)
> @@ -911,7 +917,9 @@ static int sx9500_probe(struct i2c_client *client)
>  	indio_dev->modes = INDIO_DIRECT_MODE;
>  	i2c_set_clientdata(client, indio_dev);
>  
> -	sx9500_gpio_probe(client, data);
> +	ret = sx9500_gpio_probe(client, data);
> +	if (ret)
> +		return ret;
>  
>  	ret = sx9500_init_device(indio_dev);
>  	if (ret < 0)
> 

[PATCH 14/15] iio: scmi: use 64-bit divisions for rates and intervals

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

do_div() only uses the low 32 bits of its divisor.  Two divisors in this
driver need more:

- scmi_iio_set_odr_val() divides by the requested sampling frequency in
  micro-Hertz, which exceeds 32 bits from 4295 Hz on.  The update interval
  sent to the firmware is then computed from the wrong frequency.
- convert_ns_to_freq() divides by the update interval in nanoseconds, which
  exceeds 32 bits from 4.3 seconds on.  The sampling frequency and the list
  of available frequencies of a slow sensor are reported wrong.

Use div64_u64().  A requested frequency of 0, which was a division by zero,
is refused with -EINVAL like other values that cannot be represented.

Fixes: f774117c96f9 ("iio/scmi: Adding support for IIO SCMI Based Sensors")
Cc: stable <stable@kernel.org>
Cc: Jyoti Bhayana <jbhayana@google.com>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/common/scmi_sensors/scmi_iio.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c b/drivers/iio/common/scmi_sensors/scmi_iio.c
index 442b40ef27cf..0e51e9c16b90 100644
--- a/drivers/iio/common/scmi_sensors/scmi_iio.c
+++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
@@ -161,8 +161,7 @@ static int scmi_iio_set_odr_val(struct iio_dev *iio_dev, int val, int val2)
 	do_div(sf,  MICROHZ_PER_HZ);
 	mult = scnprintf(buf, sizeof(buf), "%llu", sf) - 1;
 
-	sec = int_pow(10, mult) * MICROHZ_PER_HZ;
-	do_div(sec, uHz);
+	sec = uHz ? div64_u64(int_pow(10, mult) * MICROHZ_PER_HZ, uHz) : 0;
 	if (sec == 0) {
 		dev_err(&iio_dev->dev,
 			"Trying to set invalid sensor update value for sensor %s",
@@ -237,13 +236,10 @@ static int scmi_iio_read_avail(struct iio_dev *iio_dev,
 
 static void convert_ns_to_freq(u64 interval_ns, u64 *hz, u64 *uhz)
 {
-	u64 rem, freq;
+	u64 rem;
 
-	freq = NSEC_PER_SEC;
-	rem = do_div(freq, interval_ns);
-	*hz = freq;
-	*uhz = rem * 1000000UL;
-	do_div(*uhz, interval_ns);
+	*hz = div64_u64_rem(NSEC_PER_SEC, interval_ns, &rem);
+	*uhz = div64_u64(rem * 1000000UL, interval_ns);
 }
 
 static int scmi_iio_get_odr_val(struct iio_dev *iio_dev, int *val, int *val2)

-- 
2.56.0

Re: [PATCH 14/15] iio: scmi: use 64-bit divisions for rates and intervals

[Jonathan Cameron]

On Tue, 27 Oct 2026 17:19:18 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> From: Josef Bacik <josef@toxicpanda.com>
> 
> do_div() only uses the low 32 bits of its divisor.  Two divisors in this
> driver need more:
> 
> - scmi_iio_set_odr_val() divides by the requested sampling frequency in
>   micro-Hertz, which exceeds 32 bits from 4295 Hz on.  The update interval
>   sent to the firmware is then computed from the wrong frequency.
> - convert_ns_to_freq() divides by the update interval in nanoseconds, which
>   exceeds 32 bits from 4.3 seconds on.  The sampling frequency and the list
>   of available frequencies of a slow sensor are reported wrong.
> 
> Use div64_u64().  A requested frequency of 0, which was a division by zero,
> is refused with -EINVAL like other values that cannot be represented.
> 
> Fixes: f774117c96f9 ("iio/scmi: Adding support for IIO SCMI Based Sensors")
> Cc: stable <stable@kernel.org>
> Cc: Jyoti Bhayana <jbhayana@google.com>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We have some other fixes in this area. They don't completely overlap
though much of the content does match.

https://lore.kernel.org/all/20261006045244.13993-1-kapoorarnav43@gmail.com/

> ---
>  drivers/iio/common/scmi_sensors/scmi_iio.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c b/drivers/iio/common/scmi_sensors/scmi_iio.c
> index 442b40ef27cf..0e51e9c16b90 100644
> --- a/drivers/iio/common/scmi_sensors/scmi_iio.c
> +++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
> @@ -161,8 +161,7 @@ static int scmi_iio_set_odr_val(struct iio_dev *iio_dev, int val, int val2)
>  	do_div(sf,  MICROHZ_PER_HZ);
>  	mult = scnprintf(buf, sizeof(buf), "%llu", sf) - 1;
>  
> -	sec = int_pow(10, mult) * MICROHZ_PER_HZ;
> -	do_div(sec, uHz);
> +	sec = uHz ? div64_u64(int_pow(10, mult) * MICROHZ_PER_HZ, uHz) : 0;
>  	if (sec == 0) {
>  		dev_err(&iio_dev->dev,
>  			"Trying to set invalid sensor update value for sensor %s",
> @@ -237,13 +236,10 @@ static int scmi_iio_read_avail(struct iio_dev *iio_dev,
>  
>  static void convert_ns_to_freq(u64 interval_ns, u64 *hz, u64 *uhz)
>  {
> -	u64 rem, freq;
> +	u64 rem;
>  
> -	freq = NSEC_PER_SEC;
> -	rem = do_div(freq, interval_ns);
> -	*hz = freq;
> -	*uhz = rem * 1000000UL;
> -	do_div(*uhz, interval_ns);
> +	*hz = div64_u64_rem(NSEC_PER_SEC, interval_ns, &rem);
> +	*uhz = div64_u64(rem * 1000000UL, interval_ns);
>  }
>  
>  static int scmi_iio_get_odr_val(struct iio_dev *iio_dev, int *val, int *val2)
> 

[PATCH 15/15] iio: sx9310: use the data of the I2C table

[Greg Kroah-Hartman]

From: Josef Bacik <josef@toxicpanda.com>

sx9310_check_whoami() takes the chip information from
device_get_match_data(), which only looks at the OF and ACPI tables, and
dereferences it. For a client which was bound through the i2c_device_id
table, for instance one created with

  echo sx9310 0x28 > /sys/bus/i2c/devices/i2c-1/new_device

it returns NULL, and the kernel oopses as soon as something at that address
answers the read of the WHOAMI register.

The I2C table has the same pointers. Use i2c_get_match_data(), which falls
back to it.

Fixes: 21fd3b1373f6 ("iio: proximity: sx9310: Convert enum->pointer for match data table")
Cc: stable <stable@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
Cc: Siratul Islam <email@sirat.me>
Cc: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Biju Das <biju.das.jz@bp.renesas.com>
Cc: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/iio/proximity/sx9310.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/sx9310.c b/drivers/iio/proximity/sx9310.c
index 79ba46d8a0aa..2585b9c6fb69 100644
--- a/drivers/iio/proximity/sx9310.c
+++ b/drivers/iio/proximity/sx9310.c
@@ -891,7 +891,7 @@ static int sx9310_check_whoami(struct device *dev,
 	if (ret)
 		return ret;
 
-	ddata = device_get_match_data(dev);
+	ddata = i2c_get_match_data(data->client);
 	if (ddata->whoami != whoami)
 		return -ENODEV;
 

-- 
2.56.0

RE: [PATCH 15/15] iio: sx9310: use the data of the I2C table

[Biju Das]

Hi Greg/Josef,

> -----Original Message-----
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Sent: 27 October 2026 16:19
> Subject: [PATCH 15/15] iio: sx9310: use the data of the I2C table
> 
> From: Josef Bacik <josef@toxicpanda.com>
> 
> sx9310_check_whoami() takes the chip information from device_get_match_data(), which only looks at the OF
> and ACPI tables, and dereferences it. For a client which was bound through the i2c_device_id table, for
> instance one created with

Not sure we can extend device_get_match_data() to cover this use case?

Cheers,
Biju
> 
>   echo sx9310 0x28 > /sys/bus/i2c/devices/i2c-1/new_device
> 
> it returns NULL, and the kernel oopses as soon as something at that address answers the read of the
> WHOAMI register.
> 
> The I2C table has the same pointers. Use i2c_get_match_data(), which falls back to it.
> 
> Fixes: 21fd3b1373f6 ("iio: proximity: sx9310: Convert enum->pointer for match data table")
> Cc: stable <stable@kernel.org>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
> Cc: Siratul Islam <email@sirat.me>
> Cc: Matti Vaittinen <mazziesaccount@gmail.com>
> Cc: Biju Das <biju.das.jz@bp.renesas.com>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/iio/proximity/sx9310.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/proximity/sx9310.c b/drivers/iio/proximity/sx9310.c index
> 79ba46d8a0aa..2585b9c6fb69 100644
> --- a/drivers/iio/proximity/sx9310.c
> +++ b/drivers/iio/proximity/sx9310.c
> @@ -891,7 +891,7 @@ static int sx9310_check_whoami(struct device *dev,
>  	if (ret)
>  		return ret;
> 
> -	ddata = device_get_match_data(dev);
> +	ddata = i2c_get_match_data(data->client);
>  	if (ddata->whoami != whoami)
>  		return -ENODEV;
> 
> 
> --
> 2.56.0

Re: [PATCH 15/15] iio: sx9310: use the data of the I2C table

[Andy Shevchenko]

On Tue, Oct 27, 2026 at 04:25:30PM +0000, Biju Das wrote:
> > -----Original Message-----
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Sent: 27 October 2026 16:19
> > 
> > sx9310_check_whoami() takes the chip information from device_get_match_data(), which only looks at the OF
> > and ACPI tables, and dereferences it. For a client which was bound through the i2c_device_id table, for
> > instance one created with
> 
> Not sure we can extend device_get_match_data() to cover this use case?

It will be layering violation. device_get_match_data() has no clue what i2c or
spi or whatever bus is. So, the answer is definitely "no". (Technically, of
course, it's doable, but see above.)

-- 
With Best Regards,
Andy Shevchenko