From: sashiko-bot@kernel.org
To: "Javier Carrasco" <javier.carrasco.cruz@gmail.com>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v3 07/11] hwmon: chipcap2: enable IRQ processing when regulator is already enabled
Date: Wed, 14 Oct 2026 18:36:32 +0000 [thread overview]
Message-ID: <sashiko-outbox-171713@kernel.org> (raw)
In-Reply-To: <20261014-chipcap2_locks-v3-7-27ebfc2c5b9e@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] hwmon: chipcap2: edge-triggered alarms lost for always-on devices
--
commit d3d969f96bc4b1b75c3078d08aa3eae3d286d7f8
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
hwmon: chipcap2: enable IRQ processing when regulator is already enabled
This commit sets process_irqs to true before returning from cc2_enable()
when the regulator is already enabled. This prevents operations from timing
out by ensuring the ready interrupt is not ignored.
> diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
> index 654f6420da7ab..837b1830f2e4e 100644
> --- a/drivers/hwmon/chipcap2.c
> +++ b/drivers/hwmon/chipcap2.c
> @@ -120,8 +120,10 @@ static int cc2_enable(struct cc2_data *data)
> int ret;
>
> /* exclusive regulator, check in case a disable failed */
> - if (regulator_is_enabled(data->regulator))
> + if (regulator_is_enabled(data->regulator)) {
> + data->process_irqs = true;
> return 0;
> + }
[Severity: Medium]
While this ensures process_irqs is set to true during cc2_enable() for
always-on regulators, does this fully resolve the missed interrupts?
Looking at cc2_disable() in drivers/hwmon/chipcap2.c, process_irqs is
cleared when the driver becomes idle:
drivers/hwmon/chipcap2.c:cc2_disable() {
...
/* ignore alarms triggered by voltage toggling when powering up */
data->process_irqs = false;
...
}
For always-on regulators, the device remains powered and actively
measuring even when the driver is idle. If an alarm threshold is crossed
during this time, the device will assert the edge-triggered alarm pin
(IRQF_TRIGGER_RISING) high, triggering the interrupt.
Since process_irqs is false, the interrupt handler ignores the edge, and
the pin remains high. Subsequent sysfs reads will call cc2_enable() and
set process_irqs to true, but because the pin is already high, no new
edge is generated.
Patch 9 in this series adds synchronize_irq() to wait for running
handlers, but does this handle new edge interrupts arriving after
process_irqs is set to false?
Are edge-triggered alarms permanently lost for always-on devices because
process_irqs was cleared in cc2_disable()?
>
> /* clear any pending completion */
> try_wait_for_completion(&data->complete);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014-chipcap2_locks-v3-0-27ebfc2c5b9e@gmail.com?part=7
next prev parent reply other threads:[~2026-10-14 18:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 17:33 [PATCH v3 00/11] hwmon: chipcap2: various bug fixes Javier Carrasco
2026-10-14 17:34 ` [PATCH v3 01/11] hwmon: chipcap2: fix command error diagnostics Javier Carrasco
2026-10-14 17:50 ` sashiko-bot
2026-10-14 17:34 ` [PATCH v3 02/11] hwmon: chipcap2: fix off-by-one in command mode retry loop Javier Carrasco
2026-10-14 18:01 ` sashiko-bot
2026-10-14 20:11 ` Javier Carrasco
2026-10-14 17:34 ` [PATCH v3 03/11] hwmon: chipcap2: fix be16 handling Javier Carrasco
2026-10-14 18:08 ` sashiko-bot
2026-10-14 17:34 ` [PATCH v3 04/11] hwmon: chipcap2: defer probe when IRQs are unavailable Javier Carrasco
2026-10-14 18:14 ` sashiko-bot
2026-10-14 17:34 ` [PATCH v3 05/11] hwmon: chipcap2: fix IRQ teardown ordering Javier Carrasco
2026-10-14 18:22 ` sashiko-bot
2026-10-14 17:34 ` [PATCH v3 06/11] hwmon: chipcap2: disable device after hwmon teardown Javier Carrasco
2026-10-14 18:34 ` sashiko-bot
2026-10-14 17:34 ` [PATCH v3 07/11] hwmon: chipcap2: enable IRQ processing when regulator is already enabled Javier Carrasco
2026-10-14 18:36 ` sashiko-bot [this message]
2026-10-14 17:34 ` [PATCH v3 08/11] hwmon: chipcap2: balance regulator state Javier Carrasco
2026-10-14 18:38 ` sashiko-bot
2026-10-14 17:34 ` [PATCH v3 09/11] hwmon: chipcap2: do not discard pending alarms on disable Javier Carrasco
2026-10-14 18:38 ` sashiko-bot
2026-10-14 17:34 ` [PATCH v3 10/11] hwmon: chipcap2: serialize access to the alarm indicators Javier Carrasco
2026-10-14 18:35 ` sashiko-bot
2026-10-14 17:34 ` [PATCH v3 11/11] hwmon: chipcap2: synchronize ready IRQ state Javier Carrasco
2026-10-14 18:41 ` sashiko-bot
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=sashiko-outbox-171713@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=javier.carrasco.cruz@gmail.com \
--cc=linux-hwmon@vger.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.