Some hardware implements reboot through its watchdog hardware, for example by triggering a watchdog timeout or by writing into its watchdog register set. Platform specific code starts to spread into watchdog drivers, typically by setting pointers to a callback function which is then called from the architecture's reset handler.
While global and exported callback function pointers (such as arm_pm_restart) may be acceptable as long as they are used from platform and/or architecture code, using such a mechanism across subsystems and drivers is less than desirable. Ultimately, we'll need a better solution. This patch series provides such a solution. It extends the watchdog subsystem to support reboot functionality, provides an API function call to trigger reboots, adds support for the new API to arm and arm64, and converts the drivers providing reboot functionality to use the new infrastructure. The first patch in the series implements the new API. The second and third patch modify the arm and arm64 architecture reset handlers to call the added API function. The final two patches register the reboot handlers in the sunxi and moxart watchdog drivers with the watchdog subsystem. The sunxi patch depends on the most recent patch series sumitted by Maxime Ripard. Note that I did not address the comments asking for support of multiple watchdogs with reset handlers, nor the request to add a flag to provide 'preferential' treatment for one of those watchdogs. This will require additional discussion and needs to be addressed with a later patch if needed. Key questions are how to add such support for non-DT systems, and if the scope of restart handling is a function of the driver or of the system. Also, if one of the watchdogs does not result in a complete system reset but another one does, it is not clear to me why the less-than-perfect watchdog would be configured in the first place (or how this situation would be handled today). Compile tested only for arm64. Tested on arm/moxart by Jonas Jensen. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
