From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753862AbdF0Vmd (ORCPT ); Tue, 27 Jun 2017 17:42:33 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52692 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753583AbdF0Vmb (ORCPT ); Tue, 27 Jun 2017 17:42:31 -0400 Subject: Re: [PATCH v2 1/2] drivers/watchdog: Add optional ASPEED device tree properties To: Guenter Roeck References: <20170627211734.60477-1-cbostic@linux.vnet.ibm.com> <20170627211734.60477-2-cbostic@linux.vnet.ibm.com> <20170627213216.GA4132@roeck-us.net> 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 From: Christopher Bostic Date: Tue, 27 Jun 2017 16:42:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170627213216.GA4132@roeck-us.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17062721-0024-0000-0000-000016BC810A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007287; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00879602; UDB=6.00438409; IPR=6.00659757; BA=6.00005445; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015980; XFM=3.00000015; UTC=2017-06-27 21:42:28 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062721-0025-0000-0000-00004B934846 Message-Id: <6f2a77e0-e64c-70b7-812a-6a5e8a0b5e6f@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-27_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706270338 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/27/17 4:32 PM, Guenter Roeck wrote: > 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. No these aren't bitmasks. The example was intended to indicate what could be used. In practice only a subset of each of these properties would make any sense. How would you suggest the example be formatted to convey that? Multiple examples I suppose. Thanks, Chris > Guenter >