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 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.