> >> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c > >> new file mode 100644 > >> index 0000000..7ae45cc > >> --- /dev/null > >> +++ b/drivers/watchdog/sbsa_gwdt.c > >> @@ -0,0 +1,459 @@ > >> +/* > >> + * SBSA(Server Base System Architecture) Generic Watchdog driver > >> + * > >> + * Copyright (c) 2015, Linaro Ltd. > >> + * Author: Fu Wei <fu.wei@xxxxxxxxxx> > >> + * Suravee Suthikulpanit <Suravee.Suthikulpanit@xxxxxxx> > >> + * > >> + * This program is free software; you can redistribute it and/or modify > >> + * it under the terms of the GNU General Public License 2 as published > >> + * by the Free Software Foundation. > >> + * > >> + * This program is distributed in the hope that it will be useful, > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> + * GNU General Public License for more details. > >> + * > >> + * The SBSA Generic watchdog driver is compatible with the pretimeout > >> + * concept of Linux kernel. > >> + * The timeout and pretimeout are determined by WCV or WOR. > >> + * The first watch period is set by writing WCV directly, that can > >> + * support more than 10s timeout at the maximum system counter > >> + * frequency (400MHz). > >> + * When WS0 is triggered, the second watch period (pretimeout) is > >> + * determined by one of these registers: > >> + * (1)WOR: 32bit register, this gives a maximum watch period of > >> + * around 10s at the maximum system counter frequency. It's loaded > >> + * automatically by hardware. > >> + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout", > >> + * it will be loaded in WS0 interrupt routine. If system is in > >> + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled > >> + * and WS0 == true), the ping operation will only reload WCV. > > > > Below is the field comment about ws0_mode, it says ws0_mode is only > > for rebooting in second stage timeout, but kexec/kdump can reboot in > > either first or second stage > > Great thanks for your feedback. > > yes, if kexec/kdump reboot the system before the WS0, ws0_mode may not be set. > in this case, if WS0 is triggered during the reboot(AFAIK, panic will > disable irq, and in the early boot stage of system, irq is disabled, > too.), ws0_mode will be set at the next "open" in kdump kernel > if WS0 haven't triggered until the watchdog is opened again in kdump > kernel , ws0_mode won't be set. > > ws0_mode doesn't indicate if the system is in the kdump kernel, it > indicates that if WS0 is triggered, when the watchdog is initialized. > > Do I answer your question? Yes, thanks for explanation. So it sounds better to change the comment like below? from (reboot by kexec/kdump in panic with watchdog enabled and WS0 == true) to (reboot in the pre-timeout stage and WS0 == true) Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
