From: Esben Haabendal <esben@geanix.com>
To: <sashiko-bot@kernel.org>
Cc: <sashiko-reviews@lists.linux.dev>, <conor+dt@kernel.org>,
<devicetree@vger.kernel.org>, <robh@kernel.org>
Subject: Re: [PATCH v4 4/6] iio: accel: mma8452: Support interrupt sharing
Date: Mon, 17 Aug 2026 19:13:06 +0200 [thread overview]
Message-ID: <87se4ck6vx.fsf@geanix.com> (raw)
In-Reply-To: <20260812153451.55DC91F00A3A@smtp.kernel.org> (sashiko-bot@kernel.org's message of "Wed, 12 Aug 2026 15:34:50 +0000")
<sashiko-bot@kernel.org> writes:
> --- Patch [4]: [PATCH v4 4/6] iio: accel: mma8452: Support interrupt sharing ---
> commit ae80b7f558736b5e80920be8e31037e5cc8645ba
> Author: Esben Haabendal <esben@geanix.com>
>
> iio: accel: mma8452: Support interrupt sharing
>
> This commit adds handling of runtime PM suspension in the interrupt handler.
> It also adds the IRQF_SHARED flag to the interrupt request to allow sharing
> the interrupt with other devices.
>
>> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
>> index 1fb43c5b0b72f..106cdd904dbfd 100644
>> --- a/drivers/iio/accel/mma8452.c
>> +++ b/drivers/iio/accel/mma8452.c
>> @@ -1056,14 +1056,19 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
>> struct iio_dev *indio_dev = p;
>> struct mma8452_data *data = iio_priv(indio_dev);
>> irqreturn_t ret = IRQ_NONE;
>> + int pm_status;
>> int src;
>>
>> + pm_status = pm_runtime_get_if_active(&data->client->dev);
>> + if (pm_status == 0)
>> + return IRQ_NONE; /* device is powered down */
>> +
>
> [Severity: High]
> Does this correctly handle the case where runtime PM is disabled?
If you mean when runtime PM is disabled (CONFIG_PM not set) or disabled
for the specific device, yes, I believe this is handled correctly. We
will correctly assume that the device is not powered down when
pm_runtime_get_if_active() returns an error (-EINVAL).
> When pm_runtime_disable() is called during device removal,
> pm_runtime_get_if_active() can return -EINVAL.
>
> If a shared interrupt fires from another device during this window, the
> handler will see a negative return value. Since the check is explicitly
> for == 0, the handler will proceed and attempt to read from the I2C bus while
> the device regulators might be disabled.
Ah. That does sound like an issue.
> Should this check be <= 0 instead?
No. That would break usage with runtime PM disabled in the normal cases.
We could add a boolean to struct mma8452_data to mark the device as
being removed, and then check on that also.
Or probably better, we could call free_irq() before
pm_runtime_disable(), and cause a spurious irq if/when the race occurs,
but avoid additional code in the irq handler.
>> src = i2c_smbus_read_byte_data(data->client, MMA8452_INT_SRC);
>> if (src < 0)
>> - return IRQ_NONE;
>> + goto out;
>
> [ ... ]
>
>> @@ -1690,7 +1699,7 @@ static int mma8452_probe(struct i2c_client *client)
>> dev_info(dev, "invalid irq type, setting default active low\n");
>> irq_flags = IRQF_TRIGGER_LOW;
>> }
>> - irq_flags |= IRQF_ONESHOT;
>> + irq_flags |= IRQF_ONESHOT | IRQF_SHARED;
>
> [Severity: Medium]
> With the addition of IRQF_SHARED, is synchronize_irq() needed in the runtime
> suspend path?
>
> The PM subsystem guidelines require that drivers using shared interrupts must
> call synchronize_irq() in their runtime suspend callback before powering down
> hardware. This guarantees no interrupt handler is executing mid-flight when
> the regulators are disabled.
I am not aware of this guideline, and haven't been able to locate it.
If someone could share a pointer to where I can read about this I would
be happy to be enlightened.
> Would it be safer to add this to mma8452_runtime_suspend() before the device
> is placed in standby?
I am not a runtime PM expert, but that does sounds like a good solution.
I will try to update the patch with fixes for both this and the above
mentioned issue.
>> ret = request_threaded_irq(client->irq, NULL, mma8452_interrupt,
>> irq_flags, client->name, indio_dev);
>> if (ret)
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260812-mma8452-open-drain-v4-0-bfca15d02b59@geanix.com?part=4
next prev parent reply other threads:[~2026-08-17 17:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 14:30 [PATCH v4 0/6] io: accel: mma8452: Allow open drain interrupt pin configuration Esben Haabendal
2026-08-12 14:30 ` [PATCH v4 1/6] dt-bindings: iio: accel: mma8452: Add drive-open-drain Esben Haabendal
2026-08-12 15:00 ` sashiko-bot
2026-08-12 14:30 ` [PATCH v4 2/6] iio: accel: mma8452: Optimize struct mm8452_data member orders Esben Haabendal
2026-08-12 15:12 ` sashiko-bot
2026-08-15 4:13 ` Jonathan Cameron
2026-08-17 17:10 ` Esben Haabendal
2026-08-12 14:30 ` [PATCH v4 3/6] iio: accel: mma8452: Only apply trigger type when not set by firmware Esben Haabendal
2026-08-12 15:23 ` sashiko-bot
2026-08-12 14:30 ` [PATCH v4 4/6] iio: accel: mma8452: Support interrupt sharing Esben Haabendal
2026-08-12 15:34 ` sashiko-bot
2026-08-17 17:13 ` Esben Haabendal [this message]
2026-08-14 8:09 ` Andy Shevchenko
2026-08-15 19:33 ` Jonathan Cameron
2026-08-12 14:30 ` [PATCH v4 5/6] iio: accel: mma8452: Allow open drain interrupt pin configuration Esben Haabendal
2026-08-12 15:46 ` sashiko-bot
2026-08-12 14:30 ` [PATCH v4 6/6] iio: accel: mma8452: Reuse existing dev pointer in mma8452_probe() Esben Haabendal
2026-08-12 15:56 ` sashiko-bot
2026-08-14 8:07 ` Andy Shevchenko
2026-08-14 12:56 ` Esben Haabendal
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=87se4ck6vx.fsf@geanix.com \
--to=esben@geanix.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-bot@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox