From: sashiko-bot@kernel.org
To: "Antoniu Miclaus" <antoniu.miclaus@analog.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v2 3/3] iio: accel: adxl367: add support for INT2 interrupt pin
Date: Thu, 13 Aug 2026 08:28:58 +0000 [thread overview]
Message-ID: <20260813082858.F106D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813081452.4289-4-antoniu.miclaus@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver configures the interrupt map register based on a hardcoded name priority, but ignores the corresponding IRQ line and registers the default `irq` parameter, risking an IRQ routing mismatch.
--
--- Patch [3]: [PATCH v2 3/3] iio: accel: adxl367: add support for INT2 interrupt pin ---
commit 89ea1f01faa6ff074e5199721996b317c618f006
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 updates the
driver to determine 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 8c3de11a10a37..df385740b17b5 100644
> --- a/drivers/iio/accel/adxl367.c
> +++ b/drivers/iio/accel/adxl367.c
[ ... ]
> @@ -1426,6 +1430,31 @@ 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;
> +
> + irq = fwnode_irq_get_byname(dev_fwnode(st->dev), "INT1");
> + if (irq == -EPROBE_DEFER)
> + return irq;
> + if (irq > 0) {
> + st->int_map_reg = ADXL367_REG_INT1_MAP;
> + return 0;
> + }
> +
> + irq = fwnode_irq_get_byname(dev_fwnode(st->dev), "INT2");
> + if (irq == -EPROBE_DEFER)
> + return irq;
> + if (irq > 0) {
> + st->int_map_reg = ADXL367_REG_INT2_MAP;
> + return 0;
> + }
> +
> + /* No interrupt-names: default to INT1 for backwards compatibility. */
> + st->int_map_reg = ADXL367_REG_INT1_MAP;
> + return 0;
> +}
> +
[ ... ]
> @@ -1482,6 +1511,10 @@ int adxl367_probe(struct device *dev, const struct adxl367_ops *ops,
> if (ret)
> return ret;
>
> + ret = adxl367_set_int_map_reg(st);
> + if (ret)
> + return dev_err_probe(st->dev, ret, "Failed to get interrupt\n");
> +
> ret = devm_request_threaded_irq(st->dev, irq, NULL,
> adxl367_irq_handler, IRQF_ONESHOT,
> indio_dev->name, indio_dev);
[Severity: High]
Could this cause a mismatch between the interrupt map register and the
requested irq line?
If a device tree specifies both interrupts but INT2 is listed first
(index 0), the SPI/I2C core passes the INT2 irq as the irq parameter to
adxl367_probe().
Meanwhile, adxl367_set_int_map_reg() checks INT1 first, configures the
sensor to route interrupts to the INT1 pin, and discards the retrieved
irq number.
Then devm_request_threaded_irq() registers the handler on the original irq
parameter (INT2). Does this result in the device signaling on INT1 while
the OS listens on INT2?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813081452.4289-1-antoniu.miclaus@analog.com?part=3
next prev parent reply other threads:[~2026-08-13 8:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 8:14 [PATCH v2 0/3] iio: accel: adxl367: add INT2 interrupt pin support Antoniu Miclaus
2026-08-13 8:14 ` [PATCH v2 1/3] iio: accel: adxl367: update maintainer entries Antoniu Miclaus
2026-08-14 9:23 ` Krzysztof Kozlowski
2026-08-14 12:28 ` Nuno Sá
2026-08-13 8:14 ` [PATCH v2 2/3] dt-bindings: iio: accel: adi,adxl367: add interrupt-names Antoniu Miclaus
2026-08-13 8:14 ` [PATCH v2 3/3] iio: accel: adxl367: add support for INT2 interrupt pin Antoniu Miclaus
2026-08-13 8:28 ` sashiko-bot [this message]
2026-08-14 12:28 ` Nuno Sá
2026-08-16 0:49 ` Jonathan Cameron
2026-08-17 8:42 ` Nuno Sá
2026-08-16 0:39 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260813082858.F106D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=antoniu.miclaus@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.