meson64: allow GPIO interrupts to act as wakeup sources - #10738
Merged
Merged
Conversation
The Amlogic GPIO interrupt controller claims neither .irq_set_wake nor IRQCHIP_SKIP_SET_WAKE, so enable_irq_wake() fails with -ENXIO and the interrupt is masked on the way into suspend. On ODROID-HC4 the PCF8563 alarm arrives through that controller, which leaves the board with no way back from suspend-to-idle: it goes to sleep and stays there. Add the flag, as 35 other drivers under drivers/irqchip do. The parent here is the GIC, so passing the request up with irq_chip_set_wake_parent is not an option. Verified on ODROID-HC4 with 7.2.6: without the patch the RTC alarm never fires and the board has to be power-cycled; with it the same alarm brings the board back every time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
iav
requested review from
SteeManMI,
adeepn,
igorpecovnik,
pyavitz and
rpardini
as code owners
September 16, 2026 22:50
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughFour archived Meson64 kernel patch files update ChangesMeson GPIO wakeup support
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Medium Merge Risk: ⚪ Minimal · up to The patches retain their intended wakeup change, with no actionable current-head risk identified. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
size/medium
This was referenced Sep 17, 2026
iav
added a commit
to iav/armbian
that referenced
this pull request
Sep 17, 2026
The RTL8211F on HC4 has its interrupt wired to GPIOZ_14 and the device
tree already describes it, but the node does not declare that it can wake
the board. The Realtek PHY driver registers the interrupt as a wakeup IRQ
only for nodes that say so:
if (device_property_read_bool(dev, "wakeup-source") &&
phy_interrupt_is_valid(phydev)) {
device_set_wakeup_capable(dev, true);
devm_pm_set_wake_irq(dev, phydev->irq);
}
Without the property Wake-on-LAN looks enabled and does nothing:
'ethtool -s end0 wol g' succeeds, the PHY stores the magic packet and
raises PME on its interrupt line, but that interrupt is not a wakeup
source, so it is masked entering suspend and the board sleeps through the
packet.
Measured on ODROID-HC4. Before: a magic packet left the board asleep, the
RTC alarm had to bring it back, and the network device reported
wakeup_count 0. After: the same packet wakes the board within seconds.
Added to 6.18, 7.2 and 7.3 only. The 6.12 Realtek driver has no
wakeup-source handling at all, so the property would be inert there.
Depends on the GPIO interrupt controller being able to hold a wakeup
state: the PHY interrupt arrives through meson_gpio_irq_chip, so without
IRQCHIP_SKIP_SET_WAKE (armbian#10738) this property is worse than
useless — everything reports Wake-on-LAN as enabled while the board still
cannot be woken. And on HC4 a woken board also needs PCIe suspend/resume
support (armbian#10740) to find its SATA controller afterwards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 17, 2026
EvilOlaf
approved these changes
Sep 17, 2026
Contributor
|
✅ This PR has been reviewed and approved — all set for merge! |
github-actions
Bot
added
Ready to merge
igorpecovnik
pushed a commit
that referenced
this pull request
Sep 17, 2026
The RTL8211F on HC4 has its interrupt wired to GPIOZ_14 and the device
tree already describes it, but the node does not declare that it can wake
the board. The Realtek PHY driver registers the interrupt as a wakeup IRQ
only for nodes that say so:
if (device_property_read_bool(dev, "wakeup-source") &&
phy_interrupt_is_valid(phydev)) {
device_set_wakeup_capable(dev, true);
devm_pm_set_wake_irq(dev, phydev->irq);
}
Without the property Wake-on-LAN looks enabled and does nothing:
'ethtool -s end0 wol g' succeeds, the PHY stores the magic packet and
raises PME on its interrupt line, but that interrupt is not a wakeup
source, so it is masked entering suspend and the board sleeps through the
packet.
Measured on ODROID-HC4. Before: a magic packet left the board asleep, the
RTC alarm had to bring it back, and the network device reported
wakeup_count 0. After: the same packet wakes the board within seconds.
Added to 6.18, 7.2 and 7.3 only. The 6.12 Realtek driver has no
wakeup-source handling at all, so the property would be inert there.
Depends on the GPIO interrupt controller being able to hold a wakeup
state: the PHY interrupt arrives through meson_gpio_irq_chip, so without
IRQCHIP_SKIP_SET_WAKE (#10738) this property is worse than
useless — everything reports Wake-on-LAN as enabled while the board still
cannot be woken. And on HC4 a woken board also needs PCIe suspend/resume
support (#10740) to find its SATA controller afterwards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
meson_gpio_irq_chip declares neither .irq_set_wake nor
IRQCHIP_SKIP_SET_WAKE, so enable_irq_wake() returns -ENXIO for every
interrupt behind it and the interrupt is masked entering suspend.
On ODROID-HC4 the PCF8563 RTC alarm is exactly such an interrupt
(
meson-gpio-irqchip 82 Level rtc-pcf8563), so the board enterssuspend-to-idle with nothing left to wake it: the alarm never fires and
only a power cycle brings it back.
Tested on hardware 2026-09-16, two kernels differing only in this flag:
PM: suspend-to-idle, then silence; the board did notreturn on the alarm, nor 2.5 minutes past it, and was power-cycled;
/sys/power/pm_wakeup_irqreports that interrupt.The flag, rather than
.irq_set_wake, matches what 35 other drivers underdrivers/irqchipdo. The parent here is the GIC, which has no wakeup stateof its own, so
irq_chip_set_wake_parentwould just fail.Patch added to meson64-6.12, -6.18, -7.2 and -7.3; it applies cleanly to
all four (verified against the respective kernel trees).
This is an upstream candidate: the defect is not Armbian-specific and
affects any Amlogic board whose wakeup source sits on a GPIO interrupt.
Important, please read before merging. The hardware test above ran on a
kernel that also carried a PCIe suspend/resume patch for
pci-meson.c, whichis not in this tree — it is #10740, still a draft. On ODROID-HC4 the SATA controller sits behind PCIe, and
without that patch the controller comes back unprogrammed after resume and the
board hangs — so with this flag alone the board can be woken, but it will not
survive the sleep it was woken from.
This flag is still correct and useful on its own: it is what makes any GPIO
interrupt on Amlogic capable of waking the system at all, and on boards without
PCIe there is nothing else in the way. But for HC4 it only becomes a working
suspend story together with the PCIe patch, which is now open as a draft in #10740. Please do not read the HC4 numbers here as "suspend works on HC4
after this merge".
Related work — how this fits with the other suspend patches
This patch stands on its own: it is what makes any GPIO interrupt on Amlogic
capable of waking the system, and on boards without PCIe nothing else is in the
way. The others in the series:
pci-meson.c. Requiredon HC4 for the board to survive the sleep it was woken from; without it the
PCIe controller comes back unprogrammed and the board hangs. The HC4 numbers
quoted above were measured with that patch applied.
wakeup-sourcefor the ethernet PHY, which enablesWake-on-LAN on HC4. That one depends on this flag: the PHY interrupt arrives
through the same
meson_gpio_irq_chip, so without this patch it reportsWake-on-LAN as enabled and the board still cannot be woken.
all of the above.
Summary by CodeRabbit