Re: [PATCH v9 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: mismatch between host interrupt config and sensor polarity
--

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

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

This commit updates the probe function to use the interrupt trigger type
provided by firmware instead of unconditionally hardcoding it to active-low.
If the firmware does not specify a trigger type, it falls back to the
default active-low configuration.

> 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]
If the firmware specifies a non-default interrupt polarity such as
active-high, could this result in an interrupt storm?

While this code programs the host interrupt controller with the requested
polarity, does the sensor's hardware polarity also need to be updated? 
The sensor's default active-low configuration means its inactive state is
logic high. If the host controller is configured for active-high, wouldn't 
it constantly trigger on this logic high, return IRQ_NONE from the handler,
and endlessly re-trigger?

Should the sensor's CTRL_REG3 IPOL bit be programmed to match the requested
irq_flags, ensuring the device output aligns with the host controller's
expectations?

>  		if (ret)
>  			goto buffer_cleanup;
>  	}

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