Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F307C6FD19 for ; Mon, 13 Mar 2023 10:45:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229616AbjCMKpx (ORCPT ); Mon, 13 Mar 2023 06:45:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230152AbjCMKpt (ORCPT ); Mon, 13 Mar 2023 06:45:49 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CF8152F6C for ; Mon, 13 Mar 2023 03:45:46 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id fm20-20020a05600c0c1400b003ead37e6588so10568057wmb.5 for ; Mon, 13 Mar 2023 03:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678704345; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6YaG0SWzLbweQszAk60kBLdxmB/7i6RyPeQI10oAzV4=; b=LGtukpD/p9tW2HynhY3ArpOnq71vUNWspCHDXcqL9E0H12uUGwCrNnJ8M0RxmdNpeq pAeM7HgE3lC/iWS08/SNNgrlDNCkMeXQqRuX8cwlBg4zRVpNXPW3gDjtnKxALuceF78y NdVTDObibZ8R4EtyBNCPIMcq0OgaTbkZvAM49h3p8hUGXW7fJ7YGuhjTjqQdepEuEkoV cD7UbzHMLuWJXYr4Foe1gbFD2MHYxciKwANocceIkSdzewD4rowtkp2iwkioPH9TaNKp rEBkV5vvEN+FggyOIX39CDWbzc/iJhYRAVxAyxEi2kAEgx37tlorGCa+Sd08jrlENeFY mZeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678704345; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6YaG0SWzLbweQszAk60kBLdxmB/7i6RyPeQI10oAzV4=; b=CEl0fPdkLZMOFQsuTB7EA1fQ3Jsv8tuZSd+W/mT4dDqtV4EWcPCmiru55C7XsYqiRL Q6khb8uyVIV9XmcWp4jyHG3B56+JNpF4kzL16MP3K1+JkoQKxkN99LDo0rR6/ySvAyNn 7Qw1RmUhKk67R0Ap8NrvkUrckE3loPboqIdkR/qDZ/DhCHTlu/WAf2OMQRRZLTsMsXch Ozid6/TqUoBj4HGQNqPUgrPPudltjJ6lxVq6uwm8P2nLZIyCrAzjLCEG0TRAJ1eADoLd OF7JqNTyuJq5MeK8L7xiKl2xPesj6CmaGZkbvP+jBXBvccV+IFDK2yHYlQP2yZqcGx3M M7Tg== X-Gm-Message-State: AO0yUKW/iz/N0C988JidPK7TE+0aRfEeCXaX79n/nXYUah9IBERQYsQ0 ITXNWWoYif2IYIgb9TbpFyLmeA== X-Google-Smtp-Source: AK7set+0Oc4726DzdphLUKeZrWCln4A5vSwSav6cx8LjV/d2+4mI/5d3Gg6o/COIT9hrcw7T8dFWSQ== X-Received: by 2002:a05:600c:3504:b0:3ea:d620:579b with SMTP id h4-20020a05600c350400b003ead620579bmr9852881wmq.0.1678704344899; Mon, 13 Mar 2023 03:45:44 -0700 (PDT) Received: from ?IPV6:2a05:6e02:1041:c10:8522:ca6e:1db4:96c6? ([2a05:6e02:1041:c10:8522:ca6e:1db4:96c6]) by smtp.googlemail.com with ESMTPSA id l4-20020a05600c4f0400b003dc4a47605fsm9523224wmq.8.2023.03.13.03.45.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Mar 2023 03:45:44 -0700 (PDT) Message-ID: Date: Mon, 13 Mar 2023 11:45:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v8 01/29] thermal/core: Add a generic thermal_zone_get_trip() function Content-Language: en-US To: Ido Schimmel Cc: rafael@kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rui.zhang@intel.com, Raju Rangoju , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Peter Kaestle , Hans de Goede , Mark Gross , Miquel Raynal , Amit Kucheria , Nicolas Saenz Julienne , Broadcom Kernel Team , Florian Fainelli , Ray Jui , Scott Branden , Support Opensource , Lukasz Luba , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Thara Gopinath , Andy Gross , Bjorn Andersson , =?UTF-8?Q?Niklas_S=c3=b6derlund?= , Bartlomiej Zolnierkiewicz , Krzysztof Kozlowski , Alim Akhtar , Thierry Reding , Jonathan Hunter , Eduardo Valentin , Keerthy , Kunihiko Hayashi , Masami Hiramatsu , Antoine Tenart , Srinivas Pandruvada , Dmitry Osipenko , netdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org, "Rafael J . Wysocki" , danieller@nvidia.com, vadimp@nvidia.com, petrm@nvidia.com References: <20221003092602.1323944-1-daniel.lezcano@linaro.org> <20221003092602.1323944-2-daniel.lezcano@linaro.org> From: Daniel Lezcano In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ido, On 12/03/2023 13:14, Ido Schimmel wrote: > On Mon, Oct 03, 2022 at 11:25:34AM +0200, Daniel Lezcano wrote: >> @@ -1252,9 +1319,10 @@ thermal_zone_device_register_with_trips(const char *type, struct thermal_trip *t >> goto release_device; >> >> for (count = 0; count < num_trips; count++) { >> - if (tz->ops->get_trip_type(tz, count, &trip_type) || >> - tz->ops->get_trip_temp(tz, count, &trip_temp) || >> - !trip_temp) >> + struct thermal_trip trip; >> + >> + result = thermal_zone_get_trip(tz, count, &trip); >> + if (result) >> set_bit(count, &tz->trips_disabled); >> } > > Daniel, this change makes it so that trip points with a temperature of > zero are no longer disabled. This behavior was originally added in > commit 81ad4276b505 ("Thermal: Ignore invalid trip points"). The mlxsw > driver relies on this behavior - see mlxsw_thermal_module_trips_reset() > - and with this change I see that the thermal subsystem tries to > repeatedly set the state of the associated cooling devices to the > maximum state. Other drivers might also be affected by this. > > Following patch solves the problem for me: > > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c > index 55679fd86505..b50931f84aaa 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -1309,7 +1309,7 @@ thermal_zone_device_register_with_trips(const char *type, struct thermal_trip *t > struct thermal_trip trip; > > result = thermal_zone_get_trip(tz, count, &trip); > - if (result) > + if (result || !trip.temperature) > set_bit(count, &tz->trips_disabled); > } > > Should I submit it or do you have a better idea? Thanks for reporting this, I think the fix you are proposing is correct regarding the previous behavior. However, I disagree with the commit 81ad4276b505, because it defines the zero as an invalid trip point. But some platforms have warming devices, when the temperature is too cold, eg 0°C, we enable the warming device in order to stay in the functioning temperature range. Other devices can do the same with negative temperature values. This feature is not yet upstream and the rework of the trip point should allow proper handling of cold trip points. If you can send the change to fix the regression that would be great. But keep in mind, the driver is assuming an internal thermal framework behavior. The trips_disabled is only to overcome a trip point description bug and you should not rely on it as well as not changing the trip points on the fly after they are registered. Actually, the mlxsw driver should just build a valid array of trip points without 0°C trip point and pass it to thermal_zone_device_register_with_trips(). That would be a proper change without relying on a side effect of the thermal trip bug 0°C workaround. -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog