This looks like a very useful addition to the Zephyr port. Thanks!

I think, instead of grabbing the console device and putting it to sleep, it should either rely on zephyr's power policy management or implement pm_policy_next_state, or provide a API to chose what devices to turn on and off.

Otherwise this looks good.

I think, instead of grabbing the console device and putting it to sleep, it should either rely on zephyr's power policy management or implement pm_policy_next_state, or provide a API to chose what devices to turn on and off.

Otherwise this looks good.

Thanks @VynDragon

I think the uart/console has to be manually shutdown on the nrf chips regardless of PM policy.

My understanding is that when CONFIG_SERIAL=y then serial logging is enabled for debugging which uses power, even in low power modes. We can't turn off CONFIG_SERIAL because it's needed for micropython repl.

There is some info on it here.

Power Optimisation

You can see also in the power management examples they shut down the console device manually before power off.

System off sample

I'm very new to zephyr so I could be wrong, what do you think?

Also looking at the example if might be worthwhile also implementing deepsleep with sys_poweroff();?

I have added machine.deepsleep() to this PR which completely powers down the system using sys_poweroff();

I am trying to write PM for the chips I want to support but I am nowhere near a expert on this subsystem, so take what I say with a grain of salt.

I think the uart/console has to be manually shutdown on the nrf chips regardless of PM policy.

Dont take the NRF sdk docs as exclusive reference, there are a lot of other chips :)
In theory, Power policy via residency (the default when the application doesnt implement one), guides device power via power states: https://docs.zephyrproject.org/latest/services/pm/device.html, put differently, this is a zephyr setting rather than something the application should manage in the first place, unless power management is left unconfigured. This then follows the system power management states in https://docs.zephyrproject.org/latest/services/pm/system.html.
When calling sleep, the susbsytem calculates how much time it has to shut down and come back up, and switches to the lowest possible power state listed in the DTS, the code for this is there: https://github.com/zephyrproject-rtos/zephyr/tree/main/subsys/pm/policy

You can see also in the power management examples they shut down the console device manually before power off.
System off sample

That is indeed a example of manual control of the power saving, but not of managing power states via policies. See https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/pm/latency for the default latency policy.

I am also not sure if poweroff should be deep sleep of if that should be PM_STATE_SOFT_OFF. I have implemented power off on my platform, and it conserves some ways to be powered back on, but in comparison to ESP32 deepsleep, it would match a higher power state with more ways to wake up.