Wake-on-LAN: not supported, and would not substitute for remote power #77

New issue

Open

opened 2026-08-30 16:50:36 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-08-30 16:50:36 +00:00

Owner

Asked during the #39 work: could Wake-on-LAN help? Measured on the running board rather than
assumed.

Answer: no, not as it stands

# ethtool eth0
        Supports Wake-on: d          <- "d" = disabled only. No WoL modes at all.
        Wake-on: d

# ethtool -s eth0 wol g
netlink error: cannot enable unsupported WoL mode (offset 36)

Three independent reasons, any one of which is sufficient:

No wake interrupt in the device tree. ethernet@830000 declares a single interrupt,
macirq (SPI 82). stmmac logs IRQ eth_wake_irq not found at probe. Without it the MAC has
no way to signal a wake event.
The PHY has no interrupt line wired. PHY [stmmac-0:00] driver [RTL8211E Gigabit Ethernet] (irq=POLL) - link state is polled. Even if the RTL8211E detected a magic packet
and asserted its PMEB pin, nothing is listening.
stmmac cannot discover PMT capability. No HW DMA feature register supported, so
dma_cap.pmt_magic_frame reads 0 and the driver advertises no WoL modes. This is the same
missing feature register behind No MAC Management Counters available (#63).

There is also no wakeup attribute under /sys/class/net/eth0/device/power/, i.e. the device
was never registered as wake-capable.

Could it be made to work?

Possibly, and it would need all three:

a real wake IRQ for the GMAC, wired in the DT as a second interrupt-names entry - requires
knowing whether the A80 GMAC actually has a separate PMT interrupt, which the user manual would
have to answer
the RTL8211E's PMEB/WOL pin to be physically wired on this board, and to a pin that can wake
the SoC - a hardware question for script.bin and the schematic
stmmac to be told the MAC has PMT, since it cannot read that from hardware here

Each is a real piece of work and the first two might simply be answered "the hardware does not do
this".

⚠️ It would not replace #5, and that matters

Worth stating plainly, because that is the appeal:

WoL wakes a suspended machine, not a powered-off one. It needs the board in a sleep state
with the PHY still powered. It cannot turn on a board that is off.
It cannot help with #3 or a crash. A board hung in SPL, or one that has panicked, is not
running the code that would arm or honour a magic packet. Those are exactly the cases #5 exists
for, and they are the ones that have actually cost physical visits.
Suspend/resume on sun9i mainline is unproven on this board. /sys/power/state offers
freeze mem, and nobody has ever tried mem here. That would need to work first, and on a
board whose A15 cluster already corrupts memory (#53), suspend is not a small ask.

So the honest framing: WoL is a power-saving feature for this board, not an availability one.
It would let an idle board sleep and be woken on demand. It would not have prevented a single one
of the physical trips this project has needed.

Suggested priority

P4-later. It is genuinely blocked behind suspend/resume working at all, it needs two hardware
questions answered, and it does not address the problem it superficially looks like it addresses.
If remote power is the goal, #5 is the issue, and a smart plug solves it completely for the price
of an afternoon.

Asked during the #39 work: could Wake-on-LAN help? Measured on the running board rather than assumed. ## Answer: no, not as it stands ``` # ethtool eth0 Supports Wake-on: d <- "d" = disabled only. No WoL modes at all. Wake-on: d # ethtool -s eth0 wol g netlink error: cannot enable unsupported WoL mode (offset 36) ``` Three independent reasons, any one of which is sufficient: 1. **No wake interrupt in the device tree.** `ethernet@830000` declares a single interrupt, `macirq` (SPI 82). stmmac logs `IRQ eth_wake_irq not found` at probe. Without it the MAC has no way to signal a wake event. 2. **The PHY has no interrupt line wired.** `PHY [stmmac-0:00] driver [RTL8211E Gigabit Ethernet] (irq=POLL)` - link state is polled. Even if the RTL8211E detected a magic packet and asserted its PMEB pin, nothing is listening. 3. **stmmac cannot discover PMT capability.** `No HW DMA feature register supported`, so `dma_cap.pmt_magic_frame` reads 0 and the driver advertises no WoL modes. This is the same missing feature register behind `No MAC Management Counters available` (#63). There is also no `wakeup` attribute under `/sys/class/net/eth0/device/power/`, i.e. the device was never registered as wake-capable. ## Could it be made to work? Possibly, and it would need all three: - a real wake IRQ for the GMAC, wired in the DT as a second `interrupt-names` entry - requires knowing whether the A80 GMAC actually has a separate PMT interrupt, which the user manual would have to answer - the RTL8211E's PMEB/WOL pin to be physically wired on this board, and to a pin that can wake the SoC - a hardware question for `script.bin` and the schematic - stmmac to be told the MAC has PMT, since it cannot read that from hardware here Each is a real piece of work and the first two might simply be answered "the hardware does not do this". ## ⚠️ It would not replace #5, and that matters Worth stating plainly, because that is the appeal: - **WoL wakes a suspended machine, not a powered-off one.** It needs the board in a sleep state with the PHY still powered. It cannot turn on a board that is off. - **It cannot help with #3 or a crash.** A board hung in SPL, or one that has panicked, is not running the code that would arm or honour a magic packet. Those are exactly the cases #5 exists for, and they are the ones that have actually cost physical visits. - Suspend/resume on sun9i mainline is **unproven on this board**. `/sys/power/state` offers `freeze mem`, and nobody has ever tried `mem` here. That would need to work first, and on a board whose A15 cluster already corrupts memory (#53), suspend is not a small ask. So the honest framing: WoL is a **power-saving** feature for this board, not an availability one. It would let an idle board sleep and be woken on demand. It would not have prevented a single one of the physical trips this project has needed. ## Suggested priority **P4-later.** It is genuinely blocked behind suspend/resume working at all, it needs two hardware questions answered, and it does not address the problem it superficially looks like it addresses. If remote power is the goal, #5 is the issue, and a smart plug solves it completely for the price of an afternoon.

tiagoagueda added the

labels

2026-08-30 16:50:36 +00:00