Re: [PATCH v4 3/6] 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] Unvalidated and unconfigured IRQ trigger types from firmware cause interrupt polarity mismatch or hardware stalls.
--

--- Patch [3]: [PATCH v4 3/6] iio: accel: mma8452: Only apply trigger type when not set by firmware ---
commit 6463a4aeb8274414532a847585e92a3f1c4195b9
Author: Esben Haabendal <esben@geanix.com>

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

This patch modifies the driver to use the IRQ trigger type specified by
the firmware instead of unconditionally forcing an active-low trigger. It
falls back to active-low if the firmware does not provide a valid trigger
type.

> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index f645a5c6fd1c2..1fb43c5b0b72f 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1683,9 +1683,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]
Will this cause an interrupt polarity mismatch if the firmware specifies
an active-high trigger?

Looking at mma8452_probe(), the driver calls mma8452_reset() earlier,
which forces CTRL_REG3 (and its IPOL bit) to the hardware default of
active low.

If the firmware specifies IRQ_TYPE_LEVEL_HIGH, the OS interrupt subsystem
is configured for active-high, but the sensor continues to assert active-low
because CTRL_REG3 is never reprogrammed to match the firmware trigger type.

Additionally, can passing edge triggers (like IRQ_TYPE_EDGE_FALLING) to a
strictly level-triggered I2C sensor cause a missed-edge race condition?
If a second event occurs before the interrupt line is deasserted, this could
permanently stall the sensor.

>  		if (ret)
>  			goto buffer_cleanup;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812-mma8452-open-drain-v4-0-bfca15d02b59@geanix.com?part=3