Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp2196172rwb; Fri, 5 Aug 2022 15:28:15 -0700 (PDT) X-Google-Smtp-Source: AA6agR6tY8G0A58f4nfb1iPHH9GtPKxlVOwfZUGZdqV4LTAopgRBr3amRBI6tqT/TYVCv5qFEOg5 X-Received: by 2002:aa7:d7cc:0:b0:43d:775:ee17 with SMTP id e12-20020aa7d7cc000000b0043d0775ee17mr8502602eds.54.1659738495103; Fri, 05 Aug 2022 15:28:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659738495; cv=none; d=google.com; s=arc-20160816; b=tcWxLvWNWyRC1Ss5wHCMaJDT3XGoB8nTB0gZ9X82pdPhfYtCzgCPp9LZJGA2dTPGmu kTIGbHp+bbx3rHVpS4/QILQhZltrqoKShw7J62caiXxUNlkSoUDQTAoOtoCigkqgKUwR yK0/3SYE04HtYD8t8jA27ZMpua88fcjihYeiwOd4sTLVzl5G0t7m39M7HNlqB683R/D9 vee6BIkVLSlaqBPoqyYZkTEVrEufCBvStmFeoMwu6sa2DvFCGuSw+11/KN2S6XLFTSOz 3gJKbbCdb87FmNaJKLkM4HS1uGLVRGQJHV5fxM8KOX5eOFzY3ZrYHHi7ty2OPRdG1UXo //gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=Sqb3DDDY6ymKLXpHg1cCPpNN3i1H+Y7M1+qegvCFOI4=; b=Cj5x8u4VONDHyeHw6OongmLXIqBEHPLzb2rD1jE56cdLWohVJvb06SvLpgFPGDCVFq egMUcY+Dyv74/oHuJukePGvkhP0tZCAdN+6ejpwkpqzNvPxUT/ipaOl5JbTdytkiPSgn Qn8YTe2eK6O23AqgtuiLxOw09TF/VnoFDENRjsArZyXRlnQAJoQTZOl3gv4DEcf0E3v8 y2WOkzV8JV7R7QXzpgwdKBf1It5afIkj25u+9+nnhrbZC3I3ir48KVJcQGmksYAt4oOf cxXXdxEEpiJFx+KDnBpNikrG0tG44RurbdruEAK6BMTjI+/4ziW58XCym92ZAIlBq0pK 0LOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=owGONwNj; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=n18gR4H9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cw9-20020a170906478900b0072b6a009383si5134628ejc.826.2022.08.05.15.27.50; Fri, 05 Aug 2022 15:28:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=owGONwNj; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=n18gR4H9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241740AbiHEWHV (ORCPT + 99 others); Fri, 5 Aug 2022 18:07:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241779AbiHEWHL (ORCPT ); Fri, 5 Aug 2022 18:07:11 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6ECB12768; Fri, 5 Aug 2022 15:07:09 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 376CD34598; Fri, 5 Aug 2022 22:07:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1659737228; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Sqb3DDDY6ymKLXpHg1cCPpNN3i1H+Y7M1+qegvCFOI4=; b=owGONwNjkyDx95TgILNkWKR92IRHXPrKWLIhdBa33xZ7TGd9cttWU2pHqMucrGfdqiwmvG 8FSURQp08XTNUmacDqe4wD8rgn3el5kbpnWUiLnTx0ASDUtt3iIGEQdqkntaJnh3w1+s7h M+lL/WvbZOiC5Ioi887IJHtx8AZs5Sc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1659737228; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Sqb3DDDY6ymKLXpHg1cCPpNN3i1H+Y7M1+qegvCFOI4=; b=n18gR4H902usgtITEMeNsF+ybYEfNiX6guWgSObTz7JeMISB3AutF5cvF615lSNyXRsJ3w VbSd4lIZz1b7cJDA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id ECB5613A9C; Fri, 5 Aug 2022 22:07:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id RmgHOIuU7WLtUgAAMHmgww (envelope-from ); Fri, 05 Aug 2022 22:07:07 +0000 Date: Sat, 6 Aug 2022 00:07:06 +0200 From: Jean Delvare To: linux-watchdog@vger.kernel.org, LKML Cc: Wim Van Sebroeck , Guenter Roeck , Mika Westerberg , "Rafael J. Wysocki" Subject: [PATCH] watchdog: wdat_wdt: Set the min and max timeout values properly Message-ID: <20220806000706.3eeafc9c@endymion.delvare> Organization: SUSE Linux X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The wdat_wdt driver is misusing the min_hw_heartbeat_ms field. This field should only be used when the hardware watchdog device should not be pinged more frequently than a specific period. The ACPI WDAT "Minimum Count" field, on the other hand, specifies the minimum timeout value that can be set. This corresponds to the min_timeout field in Linux's watchdog infrastructure. Setting min_hw_heartbeat_ms instead can cause pings to the hardware to be delayed when there is no reason for that, eventually leading to unexpected firing of the watchdog timer (and thus unexpected reboot). I'm also changing max_hw_heartbeat_ms to max_timeout for symmetry, although the use of this one isn't fundamentally wrong, but there is also no reason to enable the software-driven ping mechanism for the wdat_wdt driver. Signed-off-by: Jean Delvare Fixes: 058dfc767008 ("ACPI / watchdog: Add support for WDAT hardware watchdog") Cc: Wim Van Sebroeck Cc: Guenter Roeck Cc! Mika Westerberg Cc: Rafael J. Wysocki --- Untested, as I have no supported hardware at hand. Note to the watchdog subsystem maintainers: I must say I find the whole thing pretty confusing. First of all, the name symmetry between min_hw_heartbeat_ms and max_hw_heartbeat_ms, while these properties are completely unrelated, is heavily misleading. max_hw_heartbeat_ms is really max_hw_timeout and should be renamed to that IMHO, if we keep it at all. Secondly, the coexistence of max_timeout and max_hw_heartbeat_ms is also making the code pretty hard to understand and get right. Historically, max_timeout was already supposed to be the maximum hardware timeout value. I don't understand why a new field with that meaning was introduced, subsequently changing the original meaning of max_timeout to become a software-only limit... but only if max_hw_heartbeat_ms is set. To be honest, I'm not sold to the idea of a software-emulated maximum timeout value above what the hardware can do, but if doing that makes sense in certain situations, then I believe it should be implemented as a boolean flag (named emulate_large_timeout, for example) to complement max_timeout instead of a separate time value. Is there a reason I'm missing, why it was not done that way? Currently, a comment in watchdog.h claims that max_timeout is ignored when max_hw_heartbeat_ms is set. However in watchdog_dev.c, sysfs attribute max_timeout is created unconditionally, and max_hw_heartbeat_ms doesn't have a sysfs attribute. So userspace has no way to know if max_timeout is the hardware limit, or whether software emulation will kick in for a specified timeout value. Also, there is no complaint if both max_hw_heartbeat_ms and max_timeout are set. drivers/watchdog/wdat_wdt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- linux-5.18.orig/drivers/watchdog/wdat_wdt.c 2022-07-27 07:32:33.336928967 +0200 +++ linux-5.18/drivers/watchdog/wdat_wdt.c 2022-08-05 19:49:19.607793835 +0200 @@ -342,8 +342,8 @@ static int wdat_wdt_probe(struct platfor return -EINVAL; wdat->period = tbl->timer_period; - wdat->wdd.min_hw_heartbeat_ms = wdat->period * tbl->min_count; - wdat->wdd.max_hw_heartbeat_ms = wdat->period * tbl->max_count; + wdat->wdd.min_timeout = DIV_ROUND_UP(wdat->period * tbl->min_count, 1000); + wdat->wdd.max_timeout = wdat->period * tbl->max_count / 1000; wdat->stopped_in_sleep = tbl->flags & ACPI_WDAT_STOPPED; wdat->wdd.info = &wdat_wdt_info; wdat->wdd.ops = &wdat_wdt_ops; @@ -450,8 +450,8 @@ static int wdat_wdt_probe(struct platfor * watchdog properly after it has opened the device. In some cases * the BIOS default is too short and causes immediate reboot. */ - if (timeout * 1000 < wdat->wdd.min_hw_heartbeat_ms || - timeout * 1000 > wdat->wdd.max_hw_heartbeat_ms) { + if (timeout < wdat->min_timeout || + timeout > wdat->max_timeout) { dev_warn(dev, "Invalid timeout %d given, using %d\n", timeout, WDAT_DEFAULT_TIMEOUT); timeout = WDAT_DEFAULT_TIMEOUT; -- Jean Delvare SUSE L3 Support