Re: [PATCH v4 4/4] iio: accel: adxl367: add support for INT2 interrupt pin

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Late IRQ lookup in probe causes hardware power leak and repeated boot delays on deferral.
--

commit 0e4e153b16fef4a252e91734fb90f0480bca69d2
Author: Antoniu Miclaus <antoniu.miclaus@analog.com>

iio: accel: adxl367: add support for INT2 interrupt pin

The ADXL367 provides two independent interrupt output pins, INT1 and
INT2, each with its own event mapping register. This commit determines
the connected pin from the interrupt-names device tree property and
routes the interrupt mappings to the matching register.

> diff --git a/drivers/iio/accel/adxl367.c b/drivers/iio/accel/adxl367.c
> index 54c4d12267901..9a2312da6238c 100644
> --- a/drivers/iio/accel/adxl367.c
> +++ b/drivers/iio/accel/adxl367.c
[ ... ]
> @@ -1423,6 +1427,36 @@ static int adxl367_setup(struct adxl367_state *st)
>  	return adxl367_set_measure_en(st, true);
>  }
>  
> +static int adxl367_set_int_map_reg(struct adxl367_state *st, int irq)
> +{
> +	int ret;
> +
> +	/*
> +	 * Route the mappings to whichever of INT1/INT2 is named in the
> +	 * interrupt-names property. -EINVAL (property absent) and -ENODATA
> +	 * (name not listed) are not errors; anything else is.
> +	 */
> +	ret = fwnode_irq_get_byname(dev_fwnode(st->dev), "INT1");
> +	if (ret > 0) {
[ ... ]
> @@ -1479,6 +1513,11 @@ int adxl367_probe(struct device *dev, const struct adxl367_ops *ops,
>  	if (ret)
>  		return ret;
>  
> +	ret = adxl367_set_int_map_reg(st, irq);
> +	if (ret < 0)
> +		return dev_err_probe(st->dev, ret, "Failed to get interrupt\n");
> +	irq = ret;
> +

[Severity: Medium]
Since fwnode_irq_get_byname() inside adxl367_set_int_map_reg() can return
-EPROBE_DEFER if the interrupt controller is not yet ready, will placing this
lookup after adxl367_setup() cause repeated boot delays and leave the device
powered up on deferral?

Looking at adxl367_probe(), it resets the hardware, sleeps for 15ms, and calls
adxl367_setup() which powers up the device into measurement mode.

If adxl367_set_int_map_reg() then returns -EPROBE_DEFER, the probe aborts
without an error cleanup path to power down the device.

Could this software resource acquisition be performed before the hardware
interaction to avoid unnecessary boot stalls and power leaks during probe
deferral?

>  	ret = devm_request_threaded_irq(st->dev, irq, NULL,
>  					adxl367_irq_handler, IRQF_ONESHOT,
>  					indio_dev->name, indio_dev);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831083122.3486-1-antoniu.miclaus@analog.com?part=4