odroidhc4: let the ethernet PHY wake the board

[iav]

Description

The RTL8211F on ODROID-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.

Added to meson64-6.18, -7.2 and -7.3. Not to 6.12: that kernel's Realtek driver
has no wakeup-source handling at all — no devm_pm_set_wake_irq() call — so
the property would sit in the device tree doing nothing.

Dependencies — please do not merge before these

This patch is inert on its own, and worse than inert if merged alone: userspace
will report Wake-on-LAN as enabled while the board still cannot be woken.

• meson64: allow GPIO interrupts to act as wakeup sources armbian/build#10738 — IRQCHIP_SKIP_SET_WAKE for the Amlogic GPIO
  interrupt controller. The PHY interrupt arrives through
  meson_gpio_irq_chip; without the flag enable_irq_wake() fails with
  -ENXIO and the interrupt is masked entering suspend. Required.
• meson64: sleep and wake on ODROID-HC4 - PCIe, Wake-on-Lan and the RTC alarm armbian/build#10740 — PCIe suspend/resume for pci-meson.c (draft).
  Not required for the wake itself, but on HC4 the SATA controller sits
  behind PCIe: without it the board wakes up into a hung PCIe controller,
  which on a NAS is worse than not waking at all.

How Has This Been Tested?

Tested on ODROID-HC4, kernel 7.2.6, with both prerequisites applied.

• Before the change: a magic packet leaves the board asleep, both to the
  broadcast address and to the subnet broadcast; only the RTC alarm brings
  it back (pm_wakeup_irq reports the RTC interrupt), and the network
  device reports wakeup_count 0. The PHY has no power/wakeup in sysfs
  at all.
• After the change: the PHY gains power/wakeup, ethtool -s end0 wol g
  gives Wake-on: g, the PHY moves to wakeup=enabled by itself, and the
  same magic packet wakes the board within seconds.
• Verified first as a device tree overlay on the running board, then as
  this patch.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9642388a4c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[iav]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9642388a4c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".