On Mon, Oct 27, 2025 at 11:18:17AM +0100, Linus Walleij wrote:
Hmm... Isn't this already being discussed somewhere? I have some déjà-vu.
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
I believe the above 5 lines are not needed.
This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why.
...
- /* We do not always have an IRQ */
- if (!data->has_irq)
Wouldn't check for 0 be enough?
if (!data->irq)
return 0;
This will require to store just an irq (and perhaps we may read of local variable in ->probe(), who knows?). But size wise it's the same as current standalone boolean.