From mboxrd@z Thu Jan 1 00:00:00 1970 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 F31BBC43334 for ; Tue, 12 Jul 2022 13:06:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229781AbiGLNGZ (ORCPT ); Tue, 12 Jul 2022 09:06:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230244AbiGLNGZ (ORCPT ); Tue, 12 Jul 2022 09:06:25 -0400 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5079AB41B5 for ; Tue, 12 Jul 2022 06:06:23 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id a5so11081143wrx.12 for ; Tue, 12 Jul 2022 06:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=lU3R3A+FeDJtWJs7PhdGneGdJ2+vM2VZjpiEtp5grTY=; b=ZMfiDEuasVobiKv5Ohs9XmZ7QtNpLP4qfbi/iHo9gMOYn2LhSwigwfjzvGj+EbmFhw aZ58dSqXyat45qenKqs8JxIsJ7z8hseky5aaI1RGj1DtXp6W3n8A24FTRmJ9eUoIDNZQ bNmDxAV0vu4pl60Z9CwuJRDizNi0yj4+KeATFNzJ96me2CGL64iFiiDvyoIS/1YXoFVm iJx8oYfpXmlcOqiryh70NM5MXivRvv911FBZjOX3t0zelkuGBMRjxPB3jvPGcl4eN9O2 amonjn1YaBUh0zeqOjL40wXg0XpmxOAirgnvBphbeUtPtZkbuIgUt2gCzcHdudXEYJFy 6EgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=lU3R3A+FeDJtWJs7PhdGneGdJ2+vM2VZjpiEtp5grTY=; b=0kaCMVVfmEgwe+ztEx2rgv+AXHegAHa6ZtGL0eSn8spcDeaaBi7/Qad2ua/cebgfBf /mfPZHvmqTkivks0lV3x8mEfE3k1HlmHg+DVDBzKiMKQ0a8dUUCC6PSEPd1NYsvCA4+l b7bMjlKOTJLujJmInuoMJn41lbD8bDFj+fwJ/zRtBp6TVRSv8D+pWcvrJPxoZTSDPkzs GCv9SEpvIrXi/jI/n1AIEsINyZpcfhz6fgK5fE9s+bjdphkRZ54PHQ5CkF2/AE3lRZkk gYJtXOZUW0p1I8qPEYqkZzJFSO7TTeGhdu0bmMiY2p7oLD75BTnEjzV1TzfTTFgJflKZ 6psA== X-Gm-Message-State: AJIora8UsiUquPGWgPkD2qAgHaiH+g3jucHvcZt6jnJEeo/4kQxuzpgZ VuHx3wwBPq+q0jep1t3R1OiPmx+b/Ixuuw== X-Google-Smtp-Source: AGRyM1veNh1SFwFHd4ImrgxzvJoaw3xapybXwj312Gsclhhlcuj+v43yiNWXfZxbqbkHq5TpYqPklA== X-Received: by 2002:a05:6000:68e:b0:21d:76e3:cc80 with SMTP id bo14-20020a056000068e00b0021d76e3cc80mr22134673wrb.327.1657631181717; Tue, 12 Jul 2022 06:06:21 -0700 (PDT) Received: from ?IPV6:2a05:6e02:1041:c10:da26:64bf:ffc2:b735? ([2a05:6e02:1041:c10:da26:64bf:ffc2:b735]) by smtp.googlemail.com with ESMTPSA id o14-20020a056000010e00b0021d7ad6b9fdsm8221792wrx.57.2022.07.12.06.06.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 06:06:21 -0700 (PDT) Message-ID: Date: Tue, 12 Jul 2022 15:06:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v2 3/3] thermal/core: Fix thermal trip cross point Content-Language: en-US To: Lukasz Luba Cc: quic_manafm@quicinc.com, rui.zhang@intel.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Amit Kucheria , rafael@kernel.org References: <20220708183210.1334839-1-daniel.lezcano@linaro.org> <20220708183210.1334839-3-daniel.lezcano@linaro.org> <6ce87fbb-1460-503b-f1f1-8cf53e702cdf@arm.com> <2d680cd9-9e97-e06c-55c2-2a3a1504488e@linaro.org> <5d513646-a917-b969-b2d2-9d5f4e0e6f4d@arm.com> From: Daniel Lezcano In-Reply-To: <5d513646-a917-b969-b2d2-9d5f4e0e6f4d@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 12/07/2022 14:40, Lukasz Luba wrote: > > > On 7/12/22 13:30, Daniel Lezcano wrote: >> On 12/07/2022 13:29, Lukasz Luba wrote: >> >> [ ... ] >> >>>> @@ -511,8 +528,13 @@ void thermal_zone_device_update(struct >>>> thermal_zone_device *tz, >>>>       tz->notify_event = event; >>>> -    for (count = 0; count < tz->trips; count++) >>>> -        handle_thermal_trip(tz, count); >>>> +    if (tz->last_temperature <= tz->temperature) { >>>> +        for (count = 0; count < tz->trips; count++) >>>> +            handle_thermal_trip(tz, count); >>>> +    } else { >>>> +        for (count = tz->prev_trip; count >= 0; count--) >>>> +            handle_thermal_trip(tz, count); >>>> +    } >>> >>> In general the code look good. I have one question, though: >>> Is it always true that these trip points coming from the DT >>> and parsed in thermal_of_build_thermal_zone() populated by >>>      for_each_child_of_node(child, gchild) { >>>           thermal_of_populate_trip(gchild, &tz->trips[i++]); >>> >>> are always defined in right order in DT? >> >> Hmm, that is a good question. Even if the convention is to put the >> trip point in the ascending order, I don't find any documentation >> telling it is mandatory. Given that I don't feel particularly >> comfortable to assume that is the case. >> >> Perhaps, it would make more sense to build a map of indexes telling >> the order in the trip points and work with it instead. >> >> > > Sounds a reliable way to move forward. Maybe you could just sort in the > right order those trip points in the thermal_of_build_thermal_zone() > in an additional patch to this series? > Than this patch could stay as is, because it looks go Unfortunately, there is the manual setup as well as the ACPI. -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog