Re: [PATCH] iio: accel: bmc150: Do not configure IRQ registers if no IRQ connected

[Hans de Goede <hansg@kernel.org>]

Hi,

On 13-Jun-25 14:45, Marek Vasut wrote:
> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
> which leads to bmc150_accel_core_probe() being called with irq=0, which
> leads to bmc150_accel_interrupts_setup() never being called, which leads
> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
> non-NULL, and which triggers NULL pointer dereference. This is triggered
> e.g. from iio-sensor-proxy.
> 
> Fix this by skipping the IRQ register configuration in case there is no
> IRQ connected in hardware, in a manner similar to what the driver did in
> the very first commit which added the driver.

...

> Fixes: 8e22f477e143 ("iio: bmc150: refactor interrupt enabling")
> Signed-off-by: Marek Vasut <marek.vasut+bmc150@mailbox.org>
> ---
> Cc: "Nuno Sá" <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: Julien Stephan <jstephan@baylibre.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Salvatore Bonaccorso <carnil@debian.org>
> Cc: linux-iio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/iio/accel/bmc150-accel-core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
> index 744a034bb8b5..1c3583ade2b4 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -550,6 +550,9 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
>  	if (ret < 0)
>  		return ret;
>  
> +	if (!info)
> +		return 0;
> +
>  	/* map the interrupt to the appropriate pins */
>  	ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
>  				 (state ? info->map_bitmask : 0));

AFAIK the proper fix would be to not register any IIO-triggers. This fix will
avoid the problem, but userspace might still try to use non-working triggers
which will now silently fail.

I'm not an IIO expert, but IIRC other drivers simply skip registering their triggers
when there is no interrupt support.

Regards,

Hans