Hi Dave, On 16 September 2015 at 09:57, Dave Young <dyoung@xxxxxxxxxx> wrote: >> >> 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) " in the pre-timeout stage" means " WS0 == true", so I think we should say: (reboot with watchdog enabled and WS0 == true) Thanks for your suggestion. > > Thanks > Dave -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- 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
