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/

Reply via email to