Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Ken Sloat <KSloat@aampglobal.com>
To:     "Nicolas.Ferre@microchip.com" <Nicolas.Ferre@microchip.com>
CC:     Ken Sloat <KSloat@aampglobal.com>,
        "alexandre.belloni@free-electrons.com" 
        <alexandre.belloni@free-electrons.com>,
        "wim@iguana.be" <wim@iguana.be>,
        "linux@roeck-us.net" <linux@roeck-us.net>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [RFE]: watchdog: atmel: atmel-sama5d4-wdt
Thread-Topic: [RFE]: watchdog: atmel: atmel-sama5d4-wdt
Thread-Index: AdUfoOr5PB/8HxffRU28PtnqCbe4YA==
Date:   Mon, 10 Jun 2019 15:51:52 +0000
Message-ID: <BL0PR07MB41152EDB169FE9ED1AD3B4C9AD130@BL0PR07MB4115.namprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: aampglobal.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 41b96d04-6d08-4938-3f0f-08d6edbb8ea1
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2019 15:51:52.6063
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e20e3a66-8b9e-46e9-b859-cb654c1ec6ea
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ken.sloat@aampglobal.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR07MB5457
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: BL0PR07MB4115.namprd07.prod.outlook.com
X-MS-Exchange-CrossPremises-TransportTrafficType: Email
X-MS-Exchange-CrossPremises-TransportTrafficSubType: 
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC: 
X-MS-Exchange-CrossPremises-originalclientipaddress: 100.3.71.115
X-MS-Exchange-CrossPremises-transporttraffictype: Email
X-MS-Exchange-CrossPremises-transporttrafficsubtype: 
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating;SFV:NSPM;SKIP:0;
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: BL0PR07MB5457.namprd07.prod.outlook.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello Nicolas,

I wanted to open a discussion proposing new functionality to allow disablin=
g of the watchdog timer upon entering=20
suspend in the SAMA5D2/4.

Typical use case of a hardware watchdog timer in the kernel is a userspace =
application opens the watchdog timer and
periodically "kicks" it. If the application hits a deadlock somewhere and i=
s no longer able to kick it, then the watchdog
intervenes and often resets the processor. Such is the case for the Atmel d=
river (which also allows a watchdog interrupt
to be asserted in lieu of a system reset). In most use cases, upon entering=
 a low power/suspend state, the application=20
will no longer be able to "kick" the watchdog. If the watchdog is not disab=
led or kicked via another method, then it will
reset the system. This is the current behavior of the Atmel driver as of to=
day.

The watchdog peripheral itself does have a "WDIDLEHLT" bit however, and thi=
s is enabled via the "atmel,idle-halt" dt
property. However, this is not very useful, as it literally only makes the =
watchdog count when the CPU is active. This=20
results in non-deterministic triggering of the WDT and means that if a crit=
ical application were to crash, it may be
quite a long time before the WDT would ever trigger. Below is a similar sta=
tement made in the device-tree doc for this
peripheral:

- atmel,idle-halt: present if you want to stop the watchdog when the CPU is
		   in idle state.
	CAUTION: This property should be used with care, it actually makes the
	watchdog not counting when the CPU is in idle state, therefore the
	watchdog reset time depends on mean CPU usage and will not reset at all
	if the CPU stop working while it is in idle state, which is probably
	not what you want.

It seems to me, that it would be logical and useful to introduce a new prop=
erty that would cause the Atmel WDT
to disable on suspend and re-enable on resume. It also appears that the WDT=
 is re-initialized anyways upon
resume, so the only piece missing here would really be a dt flag and a call=
 to disable.

I would be happy to submit a patch implementing this change, but wanted to =
open up a discussion here as to the
merits of this idea as perhaps it has been considered in the past.

Thanks,
Ken Sloat