From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753831AbdF0Vc2 (ORCPT ); Tue, 27 Jun 2017 17:32:28 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:52448 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753395AbdF0VcU (ORCPT ); Tue, 27 Jun 2017 17:32:20 -0400 Date: Tue, 27 Jun 2017 14:32:16 -0700 From: Guenter Roeck To: Christopher Bostic Cc: wim@iguana.be, robh+dt@kernel.org, mark.rutland@arm.com, joel@jms.id.au, linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] drivers/watchdog: Add optional ASPEED device tree properties Message-ID: <20170627213216.GA4132@roeck-us.net> References: <20170627211734.60477-1-cbostic@linux.vnet.ibm.com> <20170627211734.60477-2-cbostic@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170627211734.60477-2-cbostic@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 04:17:33PM -0500, Christopher Bostic wrote: > Describe device tree optional properties: > > * aspeed,arm-reet - ARM CPU reset on signal > * aspeed,soc-reset - SOC reset on signal > * aspeed,sys-reset - System reset on signal > Disabling system reset may be required in situations where > one of the other watchdog engines in the system is responsible > for this. > * aspeed,interrupt - Interrupt CPU on signal > * aspeed,external-signal - Generate external signal (WDT1 and WDT2 only) > * aspeed,alt-boot - Boot from alternate block on signal > > Signed-off-by: Christopher Bostic > --- > v2 - Add 'aspeed,' prefix to all optional properties > - Add arm-reset, soc-reset, interrupt, alt-boot properties > --- > .../devicetree/bindings/watchdog/aspeed-wdt.txt | 25 ++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt > index c5e74d7..555b8b4 100644 > --- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt > @@ -8,9 +8,34 @@ Required properties: > - reg: physical base address of the controller and length of memory mapped > region > > +Optional properties: > + Signal behavior - Whenever a timeout occurs, the watchdog can be programmed > + to generate 6 types of signals: > + > + - aspeed,arm-reset: If property is present then reset ARM CPU only. > + > + - aspeed,soc-reset: If property is present then reset SOC. > + > + - aspeed,sys-reset: If property is present then reset the entire chip. > + In cases where one of the other watchdog engines > + in the system is responsible for system reset it > + may be required to not specify this property. > + > + - aspeed,interrupt: If property is present then interrupt CPU. > + > + - aspeed,external-signal: If property is present then signal is sent to > + external reset counter (only WDT1 and WDT2). > + - aspeed,alt-boot: If property is present then boot from alternate block. > + > Example: > > wdt1: watchdog@1e785000 { > compatible = "aspeed,ast2400-wdt"; > reg = <0x1e785000 0x1c>; > + aspeed,arm-reset; > + aspeed,soc-reset; > + aspeed,sys-reset; > + aspeed,interrupt; > + aspeed,external-signal; > + aspeed,alt-boot; Is that a bit mask or a value ? I would have thought that, for example, a complete system reset would include the SoC reset, and a SoC reset would include the ARM reset. Generating an interrupt while at the same time resetting the system (or part of it) doesn't seem to make much sense either. Guenter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [PATCH v2 1/2] drivers/watchdog: Add optional ASPEED device tree properties Date: Tue, 27 Jun 2017 14:32:16 -0700 Message-ID: <20170627213216.GA4132@roeck-us.net> References: <20170627211734.60477-1-cbostic@linux.vnet.ibm.com> <20170627211734.60477-2-cbostic@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20170627211734.60477-2-cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> Sender: linux-watchdog-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christopher Bostic Cc: wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org, linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On Tue, Jun 27, 2017 at 04:17:33PM -0500, Christopher Bostic wrote: > Describe device tree optional properties: > > * aspeed,arm-reet - ARM CPU reset on signal > * aspeed,soc-reset - SOC reset on signal > * aspeed,sys-reset - System reset on signal > Disabling system reset may be required in situations where > one of the other watchdog engines in the system is responsible > for this. > * aspeed,interrupt - Interrupt CPU on signal > * aspeed,external-signal - Generate external signal (WDT1 and WDT2 only) > * aspeed,alt-boot - Boot from alternate block on signal > > Signed-off-by: Christopher Bostic > --- > v2 - Add 'aspeed,' prefix to all optional properties > - Add arm-reset, soc-reset, interrupt, alt-boot properties > --- > .../devicetree/bindings/watchdog/aspeed-wdt.txt | 25 ++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt > index c5e74d7..555b8b4 100644 > --- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt > @@ -8,9 +8,34 @@ Required properties: > - reg: physical base address of the controller and length of memory mapped > region > > +Optional properties: > + Signal behavior - Whenever a timeout occurs, the watchdog can be programmed > + to generate 6 types of signals: > + > + - aspeed,arm-reset: If property is present then reset ARM CPU only. > + > + - aspeed,soc-reset: If property is present then reset SOC. > + > + - aspeed,sys-reset: If property is present then reset the entire chip. > + In cases where one of the other watchdog engines > + in the system is responsible for system reset it > + may be required to not specify this property. > + > + - aspeed,interrupt: If property is present then interrupt CPU. > + > + - aspeed,external-signal: If property is present then signal is sent to > + external reset counter (only WDT1 and WDT2). > + - aspeed,alt-boot: If property is present then boot from alternate block. > + > Example: > > wdt1: watchdog@1e785000 { > compatible = "aspeed,ast2400-wdt"; > reg = <0x1e785000 0x1c>; > + aspeed,arm-reset; > + aspeed,soc-reset; > + aspeed,sys-reset; > + aspeed,interrupt; > + aspeed,external-signal; > + aspeed,alt-boot; Is that a bit mask or a value ? I would have thought that, for example, a complete system reset would include the SoC reset, and a SoC reset would include the ARM reset. Generating an interrupt while at the same time resetting the system (or part of it) doesn't seem to make much sense either. Guenter -- 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