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 F365EEB64DD for ; Mon, 24 Jul 2023 04:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229705AbjGXEZJ (ORCPT ); Mon, 24 Jul 2023 00:25:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229644AbjGXEZI (ORCPT ); Mon, 24 Jul 2023 00:25:08 -0400 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2BA1131 for ; Sun, 23 Jul 2023 21:25:06 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-666ed230c81so3776687b3a.0 for ; Sun, 23 Jul 2023 21:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1690172706; x=1690777506; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=UPd/ArX54wqm/tpIEiEhXcXx1X1EWiF2KSiUxQCQJ7k=; b=RvsdkRDPYfr6N/6c8aZGUc/31/ZJGWi5u6uyeM4gRwE6Uozbh5mcN6VfAItdfyjeK8 lECf7dOHIeA1juGAeWddfBG56wZ1O2BX6TAkwg/4yXUs+OdBGAfqKUpCmR5igdBYHFLy i1Dt5V+/H9EaZzEAzzTCA/0ywgyJWmSnyMoBo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690172706; x=1690777506; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UPd/ArX54wqm/tpIEiEhXcXx1X1EWiF2KSiUxQCQJ7k=; b=ICu9YbfJR4g2oMWP5EU35Gah/JgbM//TtVN/rWDhTp6dYhnNwHL3TNYcGlM3RmtkBl M4qLE6vCLBEamwcEm5TxFEY8afO4HkehFTClTdaS1xZqTdJf/UanrHAFQvO/Lad9X8MP yX9uFRTF2cz1tYGTfTeO1frgzqeum9d1DxcaBr0fFpj2hqF1zZxgBmnWRlzYiYpcnntM L2Xu9nXu9WAPHAlBQnFWmcZXza5vZUXx4Z8rJRaBS90flNVrOTL8goienUGUJ76YnUFR B+vinF24ry+/+/u7oRA9jE0p35M4aOwSGwq5yxjadvJbe4zJ4i2+vHFfWTnKikmGGkGn cYIg== X-Gm-Message-State: ABy/qLYBKIRcL/PT4AzJr8MPzkSLosaviMdd+ApNPKyN6DoyoEL5UBX0 wIG49bSO+tOhgCKRTow8fDwekQ== X-Google-Smtp-Source: APBJJlH2TXjXyCI+Wm3NdTdlzQ/Md1RTpmdFKaqCFO/is9/DjNxtCBDRl3BbDb8IaKxYTeFcBvfJkw== X-Received: by 2002:a05:6a00:2196:b0:668:82fe:16f1 with SMTP id h22-20020a056a00219600b0066882fe16f1mr9170529pfi.1.1690172706143; Sun, 23 Jul 2023 21:25:06 -0700 (PDT) Received: from google.com ([2401:fa00:1:10:a3b4:a34b:d387:dea5]) by smtp.gmail.com with ESMTPSA id x48-20020a056a000bf000b00666b012baedsm6636251pfu.158.2023.07.23.21.25.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jul 2023 21:25:05 -0700 (PDT) Date: Mon, 24 Jul 2023 12:25:02 +0800 From: Chen-Yu Tsai To: Daniel Lezcano Cc: Mark Brown , Icenowy Zheng , Amit Kucheria , Zhang Rui , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, Icenowy Zheng Subject: Re: [PATCH RESEND RESEND] thermal/of: support thermal zones w/o trips subnode Message-ID: <20230724042502.GA2403526@google.com> References: <20230722122534.2279689-1-zhengxingda@iscas.ac.cn> <6d1c0915-1485-d9d6-9fff-0413fb16bd3f@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6d1c0915-1485-d9d6-9fff-0413fb16bd3f@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Sun, Jul 23, 2023 at 12:12:49PM +0200, Daniel Lezcano wrote: > > Hi Mark, > > On 22/07/2023 22:11, Mark Brown wrote: > > On Sat, Jul 22, 2023 at 08:25:34PM +0800, Icenowy Zheng wrote: > > > From: Icenowy Zheng > > > > > > Although the current device tree binding of thermal zones require the > > > trips subnode, the binding in kernel v5.15 does not require it, and many > > > device trees shipped with the kernel, for example, > > > allwinner/sun50i-a64.dtsi and mediatek/mt8183-kukui.dtsi in ARM64, still > > > comply to the old binding and contain no trips subnode. > > > > > > Allow the code to successfully register thermal zones w/o trips subnode > > > for DT binding compatibility now. > > > > > > Furtherly, the inconsistency between DTs and bindings should be resolved > > > by either adding empty trips subnode or dropping the trips subnode > > > requirement. > > > > This makes sense to me - it allows people to see the reported > > temperature even if there's no trips defined which seems more > > helpful than refusing to register. > > The binding describes the trip points as required and that since the > beginning. Not really. It was made optional in the v5.15 kernel release by commit 22fc857538c3 dt-bindings: thermal: Make trips node optional > What changed is now the code reflects the required property while before it > was permissive, that was an oversight. > > Just a reminder about the thermal framework goals: > > 1. It protects the silicon (thus critical and hot trip points) > > 2. It mitigates the temperature (thus cooling device bound to trip points) > > 3. It notifies the userspace when a trip point is crossed > > So if the thermal zone is described but without any of this goal above, it > is pointless. > > If the goal is to report the temperature only, then hwmon should be used > instead. What about thermal sensors with multiple channels? Some of the channels are indeed tied to important hardware blocks like the CPU cores and should be tied into the thermal tripping. However other channels might only be used for temperature read-out and have no such requirement. Should we be mixing thermal and hwmon APIs in the driver? > If the goal is to mitigate by userspace, then the trip point *must* be used > to prevent the userspace polling the temperature. With the trip point the > sensor will be set to fire an interrupt at the given trip temperature. > > IOW, trip points are not optional for measurement points that are used for thermal throttling / mitigation. ChenYu