Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp26517363rwd; Mon, 3 Jul 2023 10:45:07 -0700 (PDT) X-Google-Smtp-Source: APBJJlGrbJICaMF7wdqBjWNrRupeQXv8NDaXkPQeL9Zw7bnTldIuMt8c5vwamLr74BOre2WhH8Fn X-Received: by 2002:a05:6a00:cc5:b0:682:4edf:b9c2 with SMTP id b5-20020a056a000cc500b006824edfb9c2mr11479341pfv.1.1688406306785; Mon, 03 Jul 2023 10:45:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688406306; cv=none; d=google.com; s=arc-20160816; b=tWrxGZTEgMb7+WMsJ0xFTMVE1qs8jf/EPE3y5cUt1HcS/556dMyDeGKDfAyHP773YL 5choAQJyroyyFE0kzOz4ir9JnYgRGF4NGj86ReMSRVGtv4uSByVpUOdH4R4O5T3St4fn x/zGSuSjvYkkE+YMyaEOEM1clawbUvmHVkeOHunLh1NGKjTx2uN1wRhJN6qSfFrDpAaQ DexRKf8XdIVlG6NhdEXc/mRYqKhzStlvICqQRXVDa818OGrvV0ojPLkzKkpfeDdmmTaA tmczcbkRLpJDY1O7V0+3TfXen703J+FTkYYAMQ0ANwrEfYuI3Z27IWNRANUKbgWBeO2m GJKA== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=YMUtXxpxYpRox2xlhZwJpwL9gOg+UbEnP2BzFu07fHo=; fh=n+dst8OFdcbzZVUMjC0Ih6eai1i6aQ4o6uubDHqGtZk=; b=0w3bd9wCEFmQrhX0VeY5vvnjUPeYzTbr1sstilRVIp+xXTWw8oKptNpqPdjlFWVKGg Wuzp7kwvJUoGSX5sj3nhdunzVM8dwYbuc/mpCNzKF2iVn/5vHYe971d/EEkoL4aFL2V5 vBxAHfYVYhGcGkcqnuM8HSH2PaxlIYBcFp7Axj6LdmPnhz4Ak5wcnIJrteZiTv2VMs7s lQRgcjYF0BQ5W6hi4vqwdXvIyl5jadh8X1JX3UsvG8WtBfn9/NPwQHFs4iRCgU9mYzb9 Wu3T+2V0HdjlvjeGiYk7/kXOPZvXOP3HCUGl/0ogvm8OHc7d4sIkwd5E4i/Crkx+OHJ7 yiVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=eShCOhwf; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w13-20020a627b0d000000b0066df86b9458si17109797pfc.223.2023.07.03.10.44.51; Mon, 03 Jul 2023 10:45:06 -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=@collabora.com header.s=mail header.b=eShCOhwf; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230427AbjGCRPV (ORCPT + 99 others); Mon, 3 Jul 2023 13:15:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229804AbjGCRPU (ORCPT ); Mon, 3 Jul 2023 13:15:20 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA4B9CD; Mon, 3 Jul 2023 10:15:19 -0700 (PDT) Received: from notapiano.myfiosgateway.com (zone.collabora.co.uk [167.235.23.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nfraprado) by madras.collabora.co.uk (Postfix) with ESMTPSA id BB7CE6606F7D; Mon, 3 Jul 2023 18:15:16 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1688404518; bh=+FspP4SEXLpd8UGez/YnH27IKQxsKfy3tcMyJKUz3yk=; h=From:To:Cc:Subject:Date:From; b=eShCOhwfHuWkARISle8RvontgqPMwOzK0A+y0Swu8MYAf2U4nHZgrYGt/m7XnOWH1 /T909DFVycl40YdEOV0Aapa17mXExSkGDaZX0/1dp11i0YqEKfeAhovI4kZsNtPLCC cTNMxpS4LKJe2Tn4Zkqldnapn/piPFIBJJtMXSTBU7aiDh18V5QdtoUa9AjJMUCOcs trPcGvU2IcCsAVIKsAXy+9ZuHokvhUx5mFwhEu2bLyi/5jWI+sUZKnuizIOyw1+g2d BBW7T57VY23pQM+1gsjcgAsSmt30uVQ6sm0Dk5F9mO83+1A2cShO72aMGI40pf57dq k5yuX1Vy94Rsg== From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= To: "Rafael J . Wysocki" , Daniel Lezcano Cc: AngeloGioacchino Del Regno , kernel@collabora.com, =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= , Amit Kucheria , Zhang Rui , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: [PATCH] thermal/core: Don't update trip points inside the hysteresis range Date: Mon, 3 Jul 2023 13:14:44 -0400 Message-ID: <20230703171502.44657-1-nfraprado@collabora.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 When searching for the trip points that need to be set, the nearest trip point's temperature is used for the high trip, while the nearest trip point's temperature minus the hysteresis is used for the low trip. The issue with this logic is that when the current temperature is inside a trip point's hysteresis range, both high and low trips will come from the same trip point. As a consequence instability can still occur like this: * the temperature rises slightly and enters the hysteresis range of a trip point * polling happens and updates the trip points to the hysteresis range * the temperature falls slightly, exiting the hysteresis range, crossing the trip point and triggering an IRQ, the trip points are updated * repeat So even though the current hysteresis implementation prevents instability from happening due to IRQs triggering on the same temperature value, both ways, it doesn't prevent it from happening due to an IRQ on one way and polling on the other. To properly implement a hysteresis behavior, when inside the hysteresis range, don't update the trip points. This way, the previously set trip points will stay in effect, which will in a way remember the previous state (if the temperature signal came from above or below the range) and therefore have the right trip point already set. The exception is if there was no previous trip point set, in which case a previous state doesn't exist, and so it's sensible to allow the hysteresis range as trip points. Signed-off-by: NĂ­colas F. R. A. Prado --- drivers/thermal/thermal_trip.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/thermal_trip.c b/drivers/thermal/thermal_trip.c index 907f3a4d7bc8..c386ac5d8bad 100644 --- a/drivers/thermal/thermal_trip.c +++ b/drivers/thermal/thermal_trip.c @@ -57,6 +57,7 @@ void __thermal_zone_set_trips(struct thermal_zone_device *tz) { struct thermal_trip trip; int low = -INT_MAX, high = INT_MAX; + int low_trip_id = -1, high_trip_id = -2; int i, ret; lockdep_assert_held(&tz->lock); @@ -73,18 +74,34 @@ void __thermal_zone_set_trips(struct thermal_zone_device *tz) trip_low = trip.temperature - trip.hysteresis; - if (trip_low < tz->temperature && trip_low > low) + if (trip_low < tz->temperature && trip_low > low) { low = trip_low; + low_trip_id = i; + } if (trip.temperature > tz->temperature && - trip.temperature < high) + trip.temperature < high) { high = trip.temperature; + high_trip_id = i; + } } /* No need to change trip points */ if (tz->prev_low_trip == low && tz->prev_high_trip == high) return; + /* + * If the current temperature is inside a trip point's hysteresis range, + * don't update the trip points, rely on the previously set ones to + * rememember the previous state. + * + * Unless no previous trip point was set, in which case there's no + * previous state to remember. + */ + if ((tz->prev_low_trip > -INT_MAX || tz->prev_high_trip < INT_MAX) && + low_trip_id == high_trip_id) + return; + tz->prev_low_trip = low; tz->prev_high_trip = high; -- 2.41.0