Looks like it's not that easy. Many platforms define pm_reboot in the board's file(s). Additionally pm_layered does not define pm_reboot, the same applies for pm_off (pm_off can be modeled as pm_set_lowest(); irq_disable(); while(1) in pm_layered I guess ?).
Therefore I will work on removing pm_reboot() from pm_fallback implementation and create additional modules if needed (at some points pm_reboot is defined outside of pm anyway). - Robert On 08.09.2017 11:03, Robert Hartung wrote: > After a short discussion offline we decided to keep it as it is. As the > nucleo board for example, supports saving reigsters across the reset. > Therefor when entering low power modes or making a reboot, it might be > required to perform some more stuff. > > The pm_* functions will now all be combined in a single module to make > it easier to develop PM for other cpus. > > - Robert > > On 08.09.2017 10:20, Robert Hartung wrote: >> Hi *, >> >> I am working on the pm (power management) module of RIOT. Can anyone >> tell me why pm_reboot is (often) part of this module? >> >> If no one votes against it, I woud like to move *pm_reboot()* to a >> dedicated module, in order to have a reboot_fallback module as we have >> planned for pm_fallback and additionally common CPUs can implement >> specific reboot functions if required. >> >> Is 'reboot' a good module name? Or should we name it pm_reboot_fallback >> (prefix it with pm)? >> >> Background: atmega_common defines a pm_reboot, but no power management >> by default. Therefore using pm_fallback is not possible and we would >> have to duplicate existing code (bad idea!). >> >> Best, >> Robert >> > -- Robert Hartung, M.Sc. Technische Universität Braunschweig Institut für Betriebssysteme und Rechnerverbund Mühlenpfordtstr. 23, Raum 115 38106 Braunschweig Fon: +49 (531) 391 - 3264 Fax: +49 (531) 391 - 5936 E-Mail: hart...@ibr.cs.tu-bs.de _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
