Skip to content

Enable suspend/resume on Pi 5#7514

Draft
PineappleBeech wants to merge 4 commits into
raspberrypi:rpi-6.18.yfrom
PineappleBeech:suspend
Draft

Enable suspend/resume on Pi 5#7514
PineappleBeech wants to merge 4 commits into
raspberrypi:rpi-6.18.yfrom
PineappleBeech:suspend

Conversation

@PineappleBeech

Copy link
Copy Markdown

This enables suspend/resume support for Pi 5.

The watchdog should be stopped when suspending.

The wireless can be turned off with cap-power-off-card. It could be left on with keep-power-in-suspend but that does not have any benefits currently.

NVME drives currently do not work. The NVME driver puts the drive in a low power state and expects the link to be left on. The PCIe driver then turns off the link. This stops the NVME driver waking up the drive. Adding NVME_QUIRK_SIMPLE_SUSPEND to a drive fixes it.

Signed-off-by: Peter Bailey <peter.bailey@raspberrypi.com>
@popcornmix

Copy link
Copy Markdown
Collaborator

Can you describe your use case?

@PineappleBeech

Copy link
Copy Markdown
Author

This is just for testing how the drivers handle suspend/resume. The firmware does not support suspend yet. It currently stops the arm and then starts it again after one second.

The first commit should only be merged if the firmware supports suspend. The other commits should do nothing if suspend is not enabled so they could be merged before suspend works.

@popcornmix

popcornmix commented Jul 23, 2026

Copy link
Copy Markdown
Collaborator

The commits look plausible to me. Claude had some comments (that may not be an issue):

Commit 2 — watchdog: bcm2835: stop watchdog over suspend/resume. This is the solid one. It's the standard pattern used by many upstream watchdog drivers, and the implementation is idiomatic (DEFINE_SIMPLE_DEV_PM_OPS + pm_sleep_ptr, so it compiles away without CONFIG_PM_SLEEP). It still applies cleanly to our tree — the driver has no PM ops today. One edge case worth raising: it only checks watchdog_active(), which covers the userspace-opened case (WDOG_ACTIVE) but not WDOG_HW_RUNNING, which the probe sets when the bootloader left the watchdog running (bcm2835_wdt.c:207). In that state the watchdog core's keepalive worker pings the hardware, but that worker freezes during suspend, so a bootloader-armed watchdog would reset the board mid-suspend. Rare in practice on Pi, but cheap to handle.

Commit 3 — cap-power-off-card on the Pi 5 / CM5 wifi SDIO node. The rationale is sound: without keep-power-in-suspend, the MMC core needs permission to power-cycle the card across suspend, otherwise the SDIO suspend path aborts. Coverage is complete (Pi 500 includes the 5-b dts, the CM5L variants include cm5.dtsi). However, the author's claim that this commit "does nothing if suspend is not enabled" is not quite right: MMC_CAP_POWER_OFF_CARD also enables SDIO runtime PM, which changes card power behaviour at probe and whenever brcmfmac is unbound — today, on every user's board. It's probably fine, but it needs testing on the current kernel (wifi bring-up, unbind/rebind, rfkill) before merging, independent of any suspend work.

Signed-off-by: Peter Bailey <peter.bailey@raspberrypi.com>
Signed-off-by: Peter Bailey <peter.bailey@raspberrypi.com>
This makes the NVMe driver reset drives during suspend/resume.

Signed-off-by: Peter Bailey <peter.bailey@raspberrypi.com>
@PineappleBeech

Copy link
Copy Markdown
Author

I've updated the watchdog driver with the extra check.

The wireless driver prevents runtime PM while it is bound

I've added a temporary fix for NVMe drives. It works by overriding acpi_storage_d3 which has the correct effect of telling the NVMe driver that PCIe will be powered down. However, the Pi 5 does not use ACPI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants