Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

From: Fu Wei
Date: Tue Oct 13 2015 - 04:34:34 EST


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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/