[PATCH v2] iio: accel: bmc150: Fix irq assumption regression

[PATCH v2] iio: accel: bmc150: Fix irq assumption regression

[Linus Walleij]

The code in bmc150-accel-core.c unconditionally calls
bmc150_accel_set_interrupt() in the iio_buffer_setup_ops,
such as on the runtime PM resume path giving a kernel
splat like this if the device has no interrupts:

Unable to handle kernel NULL pointer dereference at virtual
  address 00000001 when read
CPU: 0 UID: 0 PID: 393 Comm: iio-sensor-prox Not tainted
  6.18.0-rc1-postmarketos-stericsson-00001-g6b43386e3737 #73 PREEMPT
Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
PC is at bmc150_accel_set_interrupt+0x98/0x194
LR is at __pm_runtime_resume+0x5c/0x64
(...)
Call trace:
bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108
bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc
__iio_update_buffers from enable_store+0x84/0xc8
enable_store from kernfs_fop_write_iter+0x154/0x1b4
kernfs_fop_write_iter from do_iter_readv_writev+0x178/0x1e4
do_iter_readv_writev from vfs_writev+0x158/0x3f4
vfs_writev from do_writev+0x74/0xe4
do_writev from __sys_trace_return+0x0/0x10

This bug seems to have been in the driver since the beginning,
but it only manifests recently, I do not know why.

Store the IRQ number in the state struct, as this is a common
pattern in other drivers, then use this to determine if we have
IRQ support or not.

Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes in v2:
- Instead of a bool has_irq in the state struct, store the Linux IRQ
  number itself and switch behaviour on that.
- Link to v1: https://lore.kernel.org/r/20251027-fix-bmc150-v1-1-ccdc968e8c37@linaro.org
---
 drivers/iio/accel/bmc150-accel-core.c | 5 +++++
 drivers/iio/accel/bmc150-accel.h      | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
index 3c5d1560b163..42ccf0316ce5 100644
--- a/drivers/iio/accel/bmc150-accel-core.c
+++ b/drivers/iio/accel/bmc150-accel-core.c
@@ -523,6 +523,10 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
 	const struct bmc150_accel_interrupt_info *info = intr->info;
 	int ret;
 
+	/* We do not always have an IRQ */
+	if (data->irq <= 0)
+		return 0;
+
 	if (state) {
 		if (atomic_inc_return(&intr->users) > 1)
 			return 0;
@@ -1696,6 +1700,7 @@ int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int irq,
 	}
 
 	if (irq > 0) {
+		data->irq = irq;
 		ret = devm_request_threaded_irq(dev, irq,
 						bmc150_accel_irq_handler,
 						bmc150_accel_irq_thread_handler,
diff --git a/drivers/iio/accel/bmc150-accel.h b/drivers/iio/accel/bmc150-accel.h
index 7a7baf52e595..e8f26198359f 100644
--- a/drivers/iio/accel/bmc150-accel.h
+++ b/drivers/iio/accel/bmc150-accel.h
@@ -58,6 +58,7 @@ enum bmc150_accel_trigger_id {
 
 struct bmc150_accel_data {
 	struct regmap *regmap;
+	int irq;
 	struct regulator_bulk_data regulators[2];
 	struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
 	struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];

---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20251027-fix-bmc150-7e568122b265

Best regards,
-- 
Linus Walleij <linus.walleij@linaro.org>

Re: [PATCH v2] iio: accel: bmc150: Fix irq assumption regression

[Nuno Sá]

On Mon, 2025-11-03 at 10:36 +0100, Linus Walleij wrote:
> The code in bmc150-accel-core.c unconditionally calls
> bmc150_accel_set_interrupt() in the iio_buffer_setup_ops,
> such as on the runtime PM resume path giving a kernel
> splat like this if the device has no interrupts:
> 
> Unable to handle kernel NULL pointer dereference at virtual
>   address 00000001 when read
> CPU: 0 UID: 0 PID: 393 Comm: iio-sensor-prox Not tainted
>   6.18.0-rc1-postmarketos-stericsson-00001-g6b43386e3737 #73 PREEMPT
> Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
> PC is at bmc150_accel_set_interrupt+0x98/0x194
> LR is at __pm_runtime_resume+0x5c/0x64
> (...)
> Call trace:
> bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108
> bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc
> __iio_update_buffers from enable_store+0x84/0xc8
> enable_store from kernfs_fop_write_iter+0x154/0x1b4
> kernfs_fop_write_iter from do_iter_readv_writev+0x178/0x1e4
> do_iter_readv_writev from vfs_writev+0x158/0x3f4
> vfs_writev from do_writev+0x74/0xe4
> do_writev from __sys_trace_return+0x0/0x10
> 
> This bug seems to have been in the driver since the beginning,
> but it only manifests recently, I do not know why.
> 
> Store the IRQ number in the state struct, as this is a common
> pattern in other drivers, then use this to determine if we have
> IRQ support or not.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Changes in v2:
> - Instead of a bool has_irq in the state struct, store the Linux IRQ
>   number itself and switch behaviour on that.
> - Link to v1: https://lore.kernel.org/r/20251027-fix-bmc150-v1-1-ccdc968e8c37@linaro.org
> ---

LGTM,

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

>  drivers/iio/accel/bmc150-accel-core.c | 5 +++++
>  drivers/iio/accel/bmc150-accel.h      | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
> index 3c5d1560b163..42ccf0316ce5 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -523,6 +523,10 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
>  	const struct bmc150_accel_interrupt_info *info = intr->info;
>  	int ret;
>  
> +	/* We do not always have an IRQ */
> +	if (data->irq <= 0)
> +		return 0;
> +
>  	if (state) {
>  		if (atomic_inc_return(&intr->users) > 1)
>  			return 0;
> @@ -1696,6 +1700,7 @@ int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int
> irq,
>  	}
>  
>  	if (irq > 0) {
> +		data->irq = irq;
>  		ret = devm_request_threaded_irq(dev, irq,
>  						bmc150_accel_irq_handler,
>  						bmc150_accel_irq_thread_handler,
> diff --git a/drivers/iio/accel/bmc150-accel.h b/drivers/iio/accel/bmc150-accel.h
> index 7a7baf52e595..e8f26198359f 100644
> --- a/drivers/iio/accel/bmc150-accel.h
> +++ b/drivers/iio/accel/bmc150-accel.h
> @@ -58,6 +58,7 @@ enum bmc150_accel_trigger_id {
>  
>  struct bmc150_accel_data {
>  	struct regmap *regmap;
> +	int irq;
>  	struct regulator_bulk_data regulators[2];
>  	struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
>  	struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
> 
> ---
> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> change-id: 20251027-fix-bmc150-7e568122b265
> 
> Best regards,

Re: [PATCH v2] iio: accel: bmc150: Fix irq assumption regression

[Andy Shevchenko]

On Mon, Nov 03, 2025 at 10:36:18AM +0100, Linus Walleij wrote:
> The code in bmc150-accel-core.c unconditionally calls
> bmc150_accel_set_interrupt() in the iio_buffer_setup_ops,
> such as on the runtime PM resume path giving a kernel
> splat like this if the device has no interrupts:
> 
> Unable to handle kernel NULL pointer dereference at virtual
>   address 00000001 when read

> CPU: 0 UID: 0 PID: 393 Comm: iio-sensor-prox Not tainted
>   6.18.0-rc1-postmarketos-stericsson-00001-g6b43386e3737 #73 PREEMPT
> Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)

These 3 lines are not important.


> PC is at bmc150_accel_set_interrupt+0x98/0x194
> LR is at __pm_runtime_resume+0x5c/0x64
> (...)
> Call trace:
> bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108
> bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc
> __iio_update_buffers from enable_store+0x84/0xc8
> enable_store from kernfs_fop_write_iter+0x154/0x1b4

> kernfs_fop_write_iter from do_iter_readv_writev+0x178/0x1e4
> do_iter_readv_writev from vfs_writev+0x158/0x3f4
> vfs_writev from do_writev+0x74/0xe4
> do_writev from __sys_trace_return+0x0/0x10

As Submitting Patches recommends the commit message is better when it has less
(unrelated) lines in traceback(s). I already mentioned that those 4 lines and
more are not needed (important), and maybe removed. I leave it to Jonathan to
tweak whilst applying.

> This bug seems to have been in the driver since the beginning,
> but it only manifests recently, I do not know why.
> 
> Store the IRQ number in the state struct, as this is a common
> pattern in other drivers, then use this to determine if we have
> IRQ support or not.

I would just assign the returned value of irq to the data field and hence drop
the '=' in ' <= 0', but I am not going to pursue this. Up to you.

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

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] iio: accel: bmc150: Fix irq assumption regression

[Jonathan Cameron]

On Mon, 3 Nov 2025 21:43:43 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Mon, Nov 03, 2025 at 10:36:18AM +0100, Linus Walleij wrote:
> > The code in bmc150-accel-core.c unconditionally calls
> > bmc150_accel_set_interrupt() in the iio_buffer_setup_ops,
> > such as on the runtime PM resume path giving a kernel
> > splat like this if the device has no interrupts:
> > 
> > Unable to handle kernel NULL pointer dereference at virtual
> >   address 00000001 when read  
> 
> > CPU: 0 UID: 0 PID: 393 Comm: iio-sensor-prox Not tainted
> >   6.18.0-rc1-postmarketos-stericsson-00001-g6b43386e3737 #73 PREEMPT
> > Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)  
> 
> These 3 lines are not important.
> 
> 
> > PC is at bmc150_accel_set_interrupt+0x98/0x194
> > LR is at __pm_runtime_resume+0x5c/0x64
> > (...)
> > Call trace:
> > bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108
> > bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc
> > __iio_update_buffers from enable_store+0x84/0xc8
> > enable_store from kernfs_fop_write_iter+0x154/0x1b4  
> 
> > kernfs_fop_write_iter from do_iter_readv_writev+0x178/0x1e4
> > do_iter_readv_writev from vfs_writev+0x158/0x3f4
> > vfs_writev from do_writev+0x74/0xe4
> > do_writev from __sys_trace_return+0x0/0x10  
> 
> As Submitting Patches recommends the commit message is better when it has less
> (unrelated) lines in traceback(s). I already mentioned that those 4 lines and
> more are not needed (important), and maybe removed. I leave it to Jonathan to
> tweak whilst applying.
I trimmed them out.

Applied to the fixes-togreg branch of iio.git.

thanks,

Jonathan

> 
> > This bug seems to have been in the driver since the beginning,
> > but it only manifests recently, I do not know why.
> > 
> > Store the IRQ number in the state struct, as this is a common
> > pattern in other drivers, then use this to determine if we have
> > IRQ support or not.  
> 
> I would just assign the returned value of irq to the data field and hence drop
> the '=' in ' <= 0', but I am not going to pursue this. Up to you.
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>