meson64: sleep and wake on ODROID-HC4 - PCIe, Wake-on-Lan and the RTC alarm - #10740

The board is meant to sleep in s2idle and wake either on its RTC alarm or on a
magic packet, with the disks and the network working afterwards. Seven patches;
each one alone looks like an unrelated fix, together they make that work.

PCIe: survive the sleep (patches 1-3, pci-meson.c, all four branches)

Unchanged from the previous revision of this PR: PM callbacks for a controller
that genpd powers off, a resume that retrains the link while the data link
layer stays down, and a poll that rebuilds the root complex after a link down
reset takes the disks away.

Wake-on-Lan reaches the PHY (patch 4, phylink.c, 7.2 and 7.3)

A board configured for WoL the usual way - nmcli, which netplan turns into a
.link file - never wakes on a magic packet. udev applies WakeOnLan= as soon
as the interface appears, and stmmac attaches the PHY only when the interface
is opened, so phylink has no PHY to offer the request to and keeps it at the
MAC. The MAC on SM1 has no wake line of its own ("IRQ eth_wake_irq not found"),
and a later ethtool call is a no-op because the state already reads as "g".

Offer the stored MAC options to the PHY as it attaches and keep at the MAC only
what the PHY does not take, as phylink_ethtool_set_wol() does. The series that
put WoL under phylink (b79fbd86c849, v6.19) left the initial state unhandled.

The MAC interrupt stays shut across a sleep (patch 5, stmmac_main.c, 7.2 and 7.3)

Resume resets the MAC in stmmac_hw_setup(), and the interrupt mask reads zero
until dwmac1000_core_init() writes it again. Device interrupts are live from
the noirq phase, so a link change in that window raises the RGMII interrupt,
which the handler no longer clears - 2e2c878a3141 relies on it staying masked.
dwmac_dma_interrupt() then prints "unexpected status 04000000" until the board
is power cycled. Shut the interrupt in suspend, open it at the end of resume,
as owl-emac does; a MAC that wakes the system through that line keeps it.

RTC alarm interrupt (patch 6, board DTS, all four branches)

The PCF8563 node is marked as a wakeup source but has no interrupt, so its alarm
reaches nothing. The INT line sits on GPIOX_5.

Tested on ODROID-HC4 with two SATA disks

Kernel built from these patches only, no overlays on the board:

• woken from s2idle by a magic packet 3/3 and by the RTC alarm 2/2;
• both disks present after every resume, no interrupt storms;
• earlier kernels carrying the same code plus debug prints: nine more sleep
  cycles, no storms;
• builds on all four branches (6.12, 6.18, 7.2, 7.3).

Not covered

• 6.12 and 6.18 have no phylink-managed WoL, so a magic packet does not wake
  those kernels;
• patch 5 touches stmmac for every board, and only HC4 was tested;
• deep sleep needs BL301 changes; this is s2idle only;
• a warm reboot leaves the SD card in UHS mode, and neither U-Boot nor the
  boot ROM reads it afterwards (CMD18 fails), so the board stops in the
  bootloader until it is power cycled. Not caused by these patches - it
  reproduces with the SPI erased - but a tester meets it first: use poweroff
  and a power cycle.

Summary by CodeRabbit

• New Features
  • ODROID-HC4 RTC alarms can now wake the system.
  • Meson PCIe devices support more reliable suspend/resume, link retraining, and automatic recovery when connections drop.
  • Wake-on-LAN settings are preserved when transitioning between the network controller and PHY.
• Bug Fixes
  • Network interrupts are managed safely across suspend and resume.
  • Improved reliability for ASMedia ASM1061 SATA controller links after system resume.

Added 21 Sep: testing shutdown on the bench turned up a defect in this very series. The link watchdog from pm-3 is not stopped on shutdown - the driver has no .shutdown - so the poll outlives the point where shutdown has taken the controller's power and clocks away, and faults reading the link registers:

Internal error: synchronous external abort: 0000000096000010
Workqueue: events meson_pcie_link_watch
pc : meson_pcie_link_up+0x18/0x50

The dying kworker then keeps RCU from finishing a grace period, and a board that reached reboot: Power down prints stalls instead of powering off. The bench log has four such faults.

pm-4 adds the .shutdown and changes how the poll is stopped: it requeues itself at the end of every run, so cancel_delayed_work_sync() is not enough on its own - catching the work while it runs, it waits for that run to finish, and the tail of that same run puts the work back. It uses disable_delayed_work_sync(), which refuses the requeue, with a matching enable_delayed_work() on resume. The suspend path gets the same treatment, where the cancel had the same hole.

Tested on ODROID-HC4: three shutdowns in a row, three reboot: Power down, no oops.

Review on the staging PR then caught two more holes of the same kind, both fixed here: the watchdog was still cancelled rather than disabled on the removal path, where the work outlives dw_pcie_host_deinit() and the devm teardown; and stmmac_resume() handed the MAC interrupt back only at the end of its successful path, while three earlier returns walked past it, leaving the disable depth one deeper each cycle.

For what it is worth, the same shape shows up elsewhere - as of 21 Sep 2026, on 7.2.6: owl-emac returns from resume past its enable_irq on error (owl-emac.c:1402-1425), and fec skips enable_irq(fep->wake_irq) when fec_enet_clk_enable() fails with WoL enabled (fec_main.c:5580-5609). Not touching them here, just noting it.

Added 22 Sep: three fixes from the review rounds, and a bench run of all of them.

Patch 4 (phylink). The wolopts_phy field is gone. It was filled only when a PHY attached and phylink_ethtool_set_wol() never refreshed it, so a mode the user had switched off with ethtool came back to the MAC when the PHY detached. phylink_disconnect_phy() now asks the PHY itself with phy_ethtool_get_wol() before phy_disconnect(). The hand-off at attach is narrowed too: the PHY is offered only what it reports as supported, since a single unknown mode makes it refuse the whole request and everything would stay on the MAC.

Patch 5 (stmmac). The disable is out of stmmac_suspend(). The line is requested with IRQF_SHARED, and kept closed for the whole sleep it would silence a co-owner that can wake the system. It is now closed at the start of stmmac_resume() and reopened on the common exit, so the window is the hardware setup only - and a MAC that owns the wake source itself is no longer an exception.

Tested on ODROID-HC4 with two SATA disks, 7.2.7, branch rebased onto current main:

• warm reboot 1/1, the board back in 45 s;
• ethtool -s end0 wol g then ip link set end0 down: the MAC takes the mode over (power/wakeup reads enabled), and hands it back to the PHY on up;
• wol d then down: the MAC takes nothing, the mode does not come back;
• three s2idle cycles woken by a magic packet: back in 10, 10 and 15 s, both disks present after each, no PCIe link rebuilds, no interrupt storms.

Added 22 Sep, later.

Patch 4 (phylink), one more review fix: a SecureOn mode the PHY holds and the MAC cannot carries the PHY's own password along, from the same phy_ethtool_get_wol() query.

Patch 7 (ASM1061 and ASPM, quirks.c, 6.18, 7.2 and 7.3). Since v6.18 the kernel enables L0s and L1 on devicetree platforms by default (f3ac2ff14834, narrowed in df5192d9bb0e); before that nothing turned ASPM on for the HC4's SATA bridge. After s2idle resume its link then died in L1 while the disk spun up - 6 of 21 cycles, each one rebuilt by the watchdog. The patch disables L0s and L1 on 1b21:0611 the way mainline does for the ASM1083 (b361663c5a40) and the 6.18 regressions (921b3f59b7b0), and the way storage drivers do for their own controllers: hpsa (e5a44df85e8d), aacraid (cf16123c9c8e), mpt3sas (ffdadd68af5a). 6.12 does not enable ASPM on devicetree platforms and needs no change.

Tested on ODROID-HC4, 7.2.7, ASPM policy default: lspci reads ASPM Disabled on both ends; 15 s2idle cycles woken by a magic packet - no link down, both disks present after each.

Added 22 Sep, evening. Patch 5 carried an imbalance CodeRabbit and Codex both flagged: stmmac_resume() decided on netif_running() whether to shut the line, and decided again, later, whether to hand it back. A local irq_off now carries that single decision to the matching enable, and the !netif_running return goes through out with ret = 0.

Bench results, 22 Sep (ODROID-HC4, 7.2.7 P1367: this series plus that fix):

• Sleep: six s2idle cycles. Five woken by a magic packet - the PHY interrupt, five seconds from the packet to PM: suspend exit; one with end0 administratively down, woken by the RTC alarm. Both disks back after every cycle, no Unbalanced enable for IRQ, no link rebuilds.
• Shutdown: four in a row, four reboot: Power down, no meson_pcie_link_watch faults.
• Warm reboot: three in a row, back in 76-78 s, no SD read errors.