From: sashiko-bot@kernel.org
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, robh@kernel.org, conor+dt@kernel.org,
Frank.Li@kernel.org
Subject: Re: [PATCH 02/11] gpio: vf610: propagate return value to callers
Date: Thu, 29 Oct 2026 13:57:45 +0000 [thread overview]
Message-ID: <sashiko-outbox-189447@kernel.org> (raw)
In-Reply-To: <20261029-gpio-vf610-fixes-v1-2-45b484b4c434@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] gpio: vf610: vf610_gpio_irq_set_wake() breaks GPIO wakeup on Vybrid SoCs
--
commit 4cb6078cbfdf301b9f65c4307b8d2ea1ba2ec0b8
Author: Peng Fan <peng.fan@nxp.com>
gpio: vf610: propagate return value to callers
This commit updates vf610_gpio_irq_set_wake() to propagate the return value
from enable_irq_wake() and disable_irq_wake() instead of unconditionally
returning 0.
> diff --git a/drivers/gpio/gpio-vf610.c b/drivers/gpio/gpio-vf610.c
> index adfa2c2d5873d..44b846ff1b936 100644
> --- a/drivers/gpio/gpio-vf610.c
> +++ b/drivers/gpio/gpio-vf610.c
> @@ -188,13 +188,14 @@ static int vf610_gpio_irq_set_wake(struct irq_data *d, u32 enable)
> {
> struct vf610_gpio_port *port =
> gpiochip_get_data(irq_data_get_irq_chip_data(d));
> + int ret;
>
> if (enable)
> - enable_irq_wake(port->irq);
> + ret = enable_irq_wake(port->irq);
> else
> - disable_irq_wake(port->irq);
> + ret = disable_irq_wake(port->irq);
>
> - return 0;
> + return ret;
[Severity: Medium]
Does propagating ret here break GPIO wakeup on Vybrid (VF500/VF610) SoCs?
On Vybrid platforms in arch/arm/boot/dts/nxp/vf/vfxxx.dtsi, all
fsl,vf610-gpio controllers (gpio0 through gpio4) inherit mscm_ir as their
interrupt parent:
arch/arm/boot/dts/nxp/vf/vfxxx.dtsi:
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
interrupt-parent = <&mscm_ir>;
ranges;
In drivers/irqchip/irq-vf610-mscm-ir.c, vf610_mscm_ir_irq_chip sets neither
.irq_set_wake nor IRQCHIP_SKIP_SET_WAKE:
drivers/irqchip/irq-vf610-mscm-ir.c:
static struct irq_chip vf610_mscm_ir_irq_chip = {
.name = "mscm-ir",
.irq_mask = irq_chip_mask_parent,
.irq_unmask = irq_chip_unmask_parent,
.irq_eoi = irq_chip_eoi_parent,
.irq_enable = vf610_mscm_ir_enable,
.irq_disable = vf610_mscm_ir_disable,
.irq_retrigger = irq_chip_retrigger_hierarchy,
.irq_set_affinity = irq_chip_set_affinity_parent,
};
When a consumer calls enable_irq_wake() on a Vybrid GPIO interrupt, the call
chain irq_set_irq_wake() -> set_irq_wake_real() -> vf610_gpio_irq_set_wake()
calls enable_irq_wake(port->irq), which invokes set_irq_wake_real() on
port->irq in kernel/irq/manage.c:
static int set_irq_wake_real(unsigned int irq, unsigned int on)
{
struct irq_desc *desc = irq_to_desc(irq);
int ret = -ENXIO;
if (irq_desc_get_chip(desc)->flags & IRQCHIP_SKIP_SET_WAKE)
return 0;
if (desc->irq_data.chip->irq_set_wake)
ret = desc->irq_data.chip->irq_set_wake(&desc->irq_data, on);
return ret;
}
Because vf610_mscm_ir_irq_chip lacks both IRQCHIP_SKIP_SET_WAKE and
.irq_set_wake, set_irq_wake_real(port->irq, 1) returns -ENXIO. Previously,
vf610_gpio_irq_set_wake() ignored this and returned 0, allowing
irq_set_irq_wake() on the child GPIO IRQ to set IRQD_WAKEUP_STATE so that
suspend_device_irq() left the GPIO pin unmasked while port->irq remained
active as a chained interrupt.
With this change (and after the follow-up commit 614715b30c6f ("gpio: vf610:
simplify with irq_set_irq_wake")), irq_set_irq_wake() on any Vybrid GPIO IRQ
fails with -ENXIO, preventing IRQD_WAKEUP_STATE from being set and causing
suspend_device_irq() to mask the wakeup GPIO interrupt in PORT_PCR(n) during
system suspend.
Should vf610_mscm_ir_irq_chip also be updated to set .irq_set_wake =
irq_chip_set_wake_parent (or IRQCHIP_SKIP_SET_WAKE) before propagating this
return value?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-gpio-vf610-fixes-v1-0-45b484b4c434@nxp.com?part=2
next prev parent reply other threads:[~2026-10-29 13:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 13:42 [PATCH 00/11] gpio: vf610: fix clocks and misc cleanup Peng Fan (OSS)
2026-10-29 13:42 ` [PATCH 01/11] dt-bindings: gpio: vf610: fix clock requirements per SoC Peng Fan (OSS)
2026-10-29 14:30 ` Frank Li
2026-10-29 13:42 ` [PATCH 02/11] gpio: vf610: propagate return value to callers Peng Fan (OSS)
2026-10-29 13:57 ` sashiko-bot [this message]
2026-10-29 13:42 ` [PATCH 03/11] gpio: vf610: simplify with irq_set_irq_wake Peng Fan (OSS)
2026-10-29 14:46 ` Daniel Baluta
2026-10-29 14:46 ` Frank Li
2026-10-29 13:42 ` [PATCH 04/11] gpio: vf610: use devm_clk_get_optional_enabled for clock handling Peng Fan (OSS)
2026-10-29 14:50 ` Frank Li
2026-10-29 13:42 ` [PATCH 05/11] gpio: vf610: drop unneeded header Peng Fan (OSS)
2026-10-29 14:51 ` Frank Li
2026-10-29 13:42 ` [PATCH 06/11] gpio: vf610: drop unnecessary wrappers Peng Fan (OSS)
2026-10-29 14:45 ` Daniel Baluta
2026-10-29 14:53 ` Frank Li
2026-10-29 13:42 ` [PATCH 07/11] arm64: dts: imx8ulp: fix gpio clocks Peng Fan (OSS)
2026-10-29 13:42 ` [PATCH 08/11] arm64: dts: imx93: " Peng Fan (OSS)
2026-10-29 13:42 ` [PATCH 09/11] arm64: dts: imx95: " Peng Fan (OSS)
2026-10-29 13:42 ` [PATCH 10/11] arm64: dts: imx952: " Peng Fan (OSS)
2026-10-29 13:42 ` [PATCH 11/11] arm64: dts: imx94: add clocks for gpio controller Peng Fan (OSS)
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-189447@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=linux-gpio@vger.kernel.org \
--cc=peng.fan@oss.nxp.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox