From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161317AbbKENrL (ORCPT ); Thu, 5 Nov 2015 08:47:11 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:41225 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031220AbbKENrI (ORCPT ); Thu, 5 Nov 2015 08:47:08 -0500 Subject: Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver To: Fu Wei , Guenter Roeck Cc: Linaro ACPI Mailman List , linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org, lkml , linux-doc@vger.kernel.org, "Rafael J. Wysocki" , Arnd Bergmann , Jonathan Corbet , Jon Masters , Pratyush Anand , Will Deacon , Wim Van Sebroeck , Catalin Marinas , Wei Fu , Rob Herring , Vipul Gandhi , Dave Young References: <1445961999-9506-1-git-send-email-fu.wei@linaro.org> <1445961999-9506-6-git-send-email-fu.wei@linaro.org> <563AE588.1080009@roeck-us.net> From: Timur Tabi Message-ID: <563B5DD8.901@codeaurora.org> Date: Thu, 5 Nov 2015 07:47:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Fu Wei wrote: > (1)It is not new. > pre-timeout concept has been used by two drivers before this driver. > and this concept has been in kernel documentation. It's "new" in that it's a new infrastructure. The private API of two other drivers doesn't count. > (1) if we don't, for this two stages timeout, we have to config them > by one value. > that means "the first stage timeout" have to be equal to "the second > stage timeout", > For example, if we need 60 second for "the second stage timeout", 30 > or less for "the first stage timeout". > then "the first stage timeout" have to be 60s too. I don't think it 's > good idea. Why do we care about two stages? Don't have a pre-timeout, and just have one stage: the WS1 reset. Ignore the WS0 interrupt, and program the timeout so that WS1 is the reset. I'm not saying that pre-timeout is a terrible idea and we should never do it. I'm saying that it's not an important feature, and we should only support it to the extent that the hardware provides the feature. We should definitely not make the driver more complicated and less safe. If we agree that an SBSA watchdog allows for a pre-timeout at half-way through timeout, and that software can't change this, then we can use WS0 as the pre-timeout and applications just have to deal with that. The hardware is programmed to reset via WS1, and all we do in the interrupt handler is notify the application that a pre-timeout has occurred. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timur Tabi Subject: Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver Date: Thu, 5 Nov 2015 07:47:04 -0600 Message-ID: <563B5DD8.901@codeaurora.org> References: <1445961999-9506-1-git-send-email-fu.wei@linaro.org> <1445961999-9506-6-git-send-email-fu.wei@linaro.org> <563AE588.1080009@roeck-us.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-watchdog-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Fu Wei , Guenter Roeck Cc: Linaro ACPI Mailman List , linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Rafael J. Wysocki" , Arnd Bergmann , Jonathan Corbet , Jon Masters , Pratyush Anand , Will Deacon , Wim Van Sebroeck , Catalin Marinas , Wei Fu , Rob Herring , Vipul Gandhi , Dave Young List-Id: devicetree@vger.kernel.org Fu Wei wrote: > (1)It is not new. > pre-timeout concept has been used by two drivers before this driver. > and this concept has been in kernel documentation. It's "new" in that it's a new infrastructure. The private API of two other drivers doesn't count. > (1) if we don't, for this two stages timeout, we have to config them > by one value. > that means "the first stage timeout" have to be equal to "the second > stage timeout", > For example, if we need 60 second for "the second stage timeout", 30 > or less for "the first stage timeout". > then "the first stage timeout" have to be 60s too. I don't think it 's > good idea. Why do we care about two stages? Don't have a pre-timeout, and just have one stage: the WS1 reset. Ignore the WS0 interrupt, and program the timeout so that WS1 is the reset. I'm not saying that pre-timeout is a terrible idea and we should never do it. I'm saying that it's not an important feature, and we should only support it to the extent that the hardware provides the feature. We should definitely not make the driver more complicated and less safe. If we agree that an SBSA watchdog allows for a pre-timeout at half-way through timeout, and that software can't change this, then we can use WS0 as the pre-timeout and applications just have to deal with that. The hardware is programmed to reset via WS1, and all we do in the interrupt handler is notify the application that a pre-timeout has occurred. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html