On Sun, Jul 31, 2016 at 9:03 PM, Nicholas Piggin <npig...@gmail.com> wrote: > On Thu, 28 Jul 2016 16:07:18 -0700 > Andrey Smirnov <andrew.smir...@gmail.com> wrote: > >> Convert fsl_rstcr_restart into a function to be registered with >> register_reset_handler(). >> >> Signed-off-by: Andrey Smirnov <andrew.smir...@gmail.com> >> --- >> >> Changes since v1: >> >> - fsl_rstcr_restart is registered as a reset handler in >> setup_rstcr, replacing per-board arch_initcall approach > > Bear in mind I don't know much about the embedded or platform code! > > The documentation for reset notifiers says that they are expected > to be registered from drivers, not arch code. That seems to only be > intended to mean that the standard ISA or platform reset would > normally be handled directly by the arch, whereas if you have an > arch specific driver for a reset hardware that just happens to live > under arch/, then fsl_rstcr_restart / mpc85xx_cds_restart would be > valid use of reset notifier.
Yeah, IMHO there's quite a bit of code in sysdev/ which in ideal world would go into drivers/ and I think fsl_rstcr_restart is among it (similar example on MIPS is drivers/power/reset/brcmstb-reboot.c). > > So this change seems reasonable to me. One small question: > > >> +static int mpc85xx_cds_restart_register(void) >> +{ >> + static struct notifier_block restart_handler; >> + >> + restart_handler.notifier_call = mpc85xx_cds_restart; >> + restart_handler.priority = 192; > > Should there be a header with #define's for these priorities? I don't have any strong preference either way, I do however think that introducing such #define should go into a separate patch-set, since you'd probably want to propagate that change across all of the users of the API. Thanks, Andrey