From patchwork Fri Nov 22 13:22:46 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christophe Roullier X-Patchwork-Id: 11257985 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0074314C0 for ; Fri, 22 Nov 2019 13:23:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D45DF2071C for ; Fri, 22 Nov 2019 13:23:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=st.com header.i=@st.com header.b="X1aI59PJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727046AbfKVNXV (ORCPT ); Fri, 22 Nov 2019 08:23:21 -0500 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:38326 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726548AbfKVNXV (ORCPT ); Fri, 22 Nov 2019 08:23:21 -0500 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAMDH5K5020334; Fri, 22 Nov 2019 14:22:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=from : to : cc : subject : date : message-id : mime-version : content-type; s=STMicroelectronics; bh=yQtLtgP4SshXnHOsAHP1arx+i7HyYqVIpwa3Jnqm8ds=; b=X1aI59PJrQVIw5W4jTHEYGmyufOTJ7KCbqVgkGEe0P2YPDG8EUF5xGo3EkmynhXISSBK 1SOwXAIb0gpuvQ5V+AuJQ3XO1Ep3a1vTpG2MHjiUvxe59qDUrtAssceNU90ECTB2tpdO htPIq9Y/tyH+Pu5yWqMXUDvxkPFGX51SUFH/cHsKegF0+W3gL7b18OIaxzQKJfbmcM+u gqEtM92PDH5tkDHTOkSTn4iXiqBOjTEevrS8ZhuRMuyGma/E8f+C9hzS4ubq7zNy1YRP Dn5ph4x2k+M5YmL6kzu0ZZbWageJzR6KsuhqyjDazDSw60YJ2NizcpOW4T9DLhzIQ1wb +A== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 2wa9ujgy24-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Nov 2019 14:22:54 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1830F100034; Fri, 22 Nov 2019 14:22:49 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag5node3.st.com [10.75.127.15]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 9E3652BE25A; Fri, 22 Nov 2019 14:22:48 +0100 (CET) Received: from localhost (10.75.127.46) by SFHDAG5NODE3.st.com (10.75.127.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Nov 2019 14:22:48 +0100 From: Christophe Roullier To: , , , CC: , , , , Subject: [PATCH v3 1/1] drivers: watchdog: stm32_iwdg: set WDOG_HW_RUNNING at probe Date: Fri, 22 Nov 2019 14:22:46 +0100 Message-ID: <20191122132246.8473-1-christophe.roullier@st.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Originating-IP: [10.75.127.46] X-ClientProxiedBy: SFHDAG1NODE3.st.com (10.75.127.3) To SFHDAG5NODE3.st.com (10.75.127.15) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-22_02:2019-11-21,2019-11-22 signatures=0 Sender: linux-watchdog-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-watchdog@vger.kernel.org If the watchdog hardware is already enabled during the boot process, when the Linux watchdog driver loads, it should start/reset the watchdog and tell the watchdog framework. As a result, ping can be generated from the watchdog framework (if CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set), until the userspace watchdog daemon takes over control Fixes:4332d113c66a ("watchdog: Add STM32 IWDG driver") Signed-off-by: Christophe Roullier Reviewed-by: Guenter Roeck --- Changes since v2: According to Guenter removed intermediate variable I've tested some config and it is working as expected: Watchdog enable in Uboot + HANDLE_BOOT_ENABLE is not set + daemon watchdog in userland ON ==> No reset IWDG2 Watchdog enable in Uboot + HANDLE_BOOT_ENABLE is not set ==> Reset IWDG2 Watchdog enable in Uboot + HANDLE_BOOT_ENABLE=y ==> No reset IWDG2 Watchdog enable in Uboot + HANDLE_BOOT_ENABLE=y + daemon watchdog in userland ON puis OFF ==> Reset IWDG2 Watchdog disable in Uboot + HANDLE_BOOT_ENABLE is not set ==> No reset IWDG2 Watchdog disable in Uboot + HANDLE_BOOT_ENABLE=y ==> No reset IWDG2 Watchdog disable in Uboot + HANDLE_BOOT_ENABLE=y + daemon watchdog in userland ON ==> No reset IWDG2 Watchdog disable in Uboot + HANDLE_BOOT_ENABLE=y + daemon watchdog in userland ON puis OFF ==> Reset IWDG2 Thanks, Christophe drivers/watchdog/stm32_iwdg.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c index a3a329011a06..25188d6bbe15 100644 --- a/drivers/watchdog/stm32_iwdg.c +++ b/drivers/watchdog/stm32_iwdg.c @@ -262,6 +262,24 @@ static int stm32_iwdg_probe(struct platform_device *pdev) watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT); watchdog_init_timeout(wdd, 0, dev); + /* + * In case of CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set + * (Means U-Boot/bootloaders leaves the watchdog running) + * When we get here we should make a decision to prevent + * any side effects before user space daemon will take care of it. + * The best option, taking into consideration that there is no + * way to read values back from hardware, is to enforce watchdog + * being run with deterministic values. + */ + if (IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED)) { + ret = stm32_iwdg_start(wdd); + if (ret) + return ret; + + /* Make sure the watchdog is serviced */ + set_bit(WDOG_HW_RUNNING, &wdd->status); + } + ret = devm_watchdog_register_device(dev, wdd); if (ret) return ret;