Re: [PATCH v10 05/10] iio: accel: mma8452: Only apply trigger type when not set by firmware

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] iio: accel: mma8452: IRQ storm due to unconfigured hardware interrupt polarity
--

commit 24f5b1347bb4e1832201e80435a781ee363c54e3
Author: Esben Haabendal <esben@geanix.com>

iio: accel: mma8452: Only apply trigger type when not set by firmware

This commit changes the mma8452 probe function to read the IRQ trigger type
from the firmware instead of unconditionally forcing it to active-low. It
falls back to active-low if the firmware does not specify a type.

> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 8d70fe89110cd..72b4ab32775a6 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1669,9 +1669,16 @@ static int mma8452_probe(struct i2c_client *client)
>  		goto trigger_cleanup;
>  
>  	if (client->irq) {
> +		unsigned long irq_flags;
> +
> +		irq_flags = irq_get_trigger_type(client->irq);
> +		if (irq_flags == IRQ_TYPE_NONE) {
> +			dev_info(dev, "invalid irq type, setting default active low\n");
> +			irq_flags = IRQF_TRIGGER_LOW;
> +		}
> +		irq_flags |= IRQF_ONESHOT;
>  		ret = request_threaded_irq(client->irq, NULL, mma8452_interrupt,
> -					   IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> -					   client->name, indio_dev);
> +					   irq_flags, client->name, indio_dev);

[Severity: High]
Does this risk an IRQ storm if the firmware specifies an active-high trigger?

By dynamically applying the firmware's IRQ trigger type to the host interrupt
controller, the host configuration might no longer match the hardware default.

If the firmware requests an active-high interrupt, the host interrupt
controller will be configured for it here. However, the driver does not appear
to write to the MMA8452 sensor's CTRL_REG3 register to set the IPOL bit. This
leaves the sensor's physical output polarity at its active-low default.

For a level-triggered interrupt, this mismatch would cause the interrupt line
to constantly fire. Since the interrupt handler returns IRQ_NONE when no events
are pending, could this result in an infinite loop?

>  		if (ret)
>  			goto buffer_cleanup;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-mma8452-open-drain-v10-0-b906fb408386@geanix.com?part=5