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;
Date:   Tue, 25 Jul 2023 12:01:58 +0800
From:   Icenowy Zheng <uwu@icenowy.me>
To:     Chen-Yu Tsai <wenst@chromium.org>,
        Daniel Lezcano <daniel.lezcano@linaro.org>
CC:     Mark Brown <broonie@kernel.org>,
        Icenowy Zheng <zhengxingda@iscas.ac.cn>,
        Amit Kucheria <amitk@kernel.org>,
        Zhang Rui <rui.zhang@intel.com>, linux-pm@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-sunxi@lists.linux.dev
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_RESEND_RESEND=5D_thermal/of=3A_?= =?US-ASCII?Q?support_thermal_zones_w/o_trips_subnode?=
User-Agent: K-9 Mail for Android
In-Reply-To: <20230724042502.GA2403526@google.com>
References: <20230722122534.2279689-1-zhengxingda@iscas.ac.cn> <ZLw4CnzLI/QHPGWx@finisterre.sirena.org.uk> <6d1c0915-1485-d9d6-9fff-0413fb16bd3f@linaro.org> <20230724042502.GA2403526@google.com>
Message-ID: <1308F9C6-F629-42BE-A72A-5BED01D1EDFB@icenowy.me>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


=E4=BA=8E 2023=E5=B9=B47=E6=9C=8824=E6=97=A5 GMT+08:00 12:25:02, Chen-Yu T=
sai <wenst@chromium=2Eorg> =E5=86=99=E5=88=B0:
>On Sun, Jul 23, 2023 at 12:12:49PM +0200, Daniel Lezcano wrote:
>>=20
>> Hi Mark,
>>=20
>> 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 <uwu@icenowy=2Eme>
>> > >=20
>> > > Although the current device tree binding of thermal zones require t=
he
>> > > trips subnode, the binding in kernel v5=2E15 does not require it, a=
nd many
>> > > device trees shipped with the kernel, for example,
>> > > allwinner/sun50i-a64=2Edtsi and mediatek/mt8183-kukui=2Edtsi in ARM=
64, still
>> > > comply to the old binding and contain no trips subnode=2E
>> > >=20
>> > > Allow the code to successfully register thermal zones w/o trips sub=
node
>> > > for DT binding compatibility now=2E
>> > >=20
>> > > Furtherly, the inconsistency between DTs and bindings should be res=
olved
>> > > by either adding empty trips subnode or dropping the trips subnode
>> > > requirement=2E
>> >=20
>> > 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=2E
>>=20
>> The binding describes the trip points as required and that since the
>> beginning=2E
>
>Not really=2E It was made optional in the v5=2E15 kernel release by commi=
t
>
>    22fc857538c3 dt-bindings: thermal: Make trips node optional

Yes, thanks for the clarification=2E

My understand of DT binding tells me that this means lacking of the trips =
node
must be handled, before we solve the inconsistency between current
DT binding and shipped DTs=2E

The latter problem could be discussed, but the former problem is a MUST
unless we're breaking the compatibility promise of DT bindings (and shippe=
d DTs)=2E

>
>> What changed is now the code reflects the required property while befor=
e it
>> was permissive, that was an oversight=2E
>>=20
>> Just a reminder about the thermal framework goals:
>>=20
>>   1=2E It protects the silicon (thus critical and hot trip points)
>>=20
>>   2=2E It mitigates the temperature (thus cooling device bound to trip =
points)
>>=20
>>   3=2E It notifies the userspace when a trip point is crossed
>>=20
>> So if the thermal zone is described but without any of this goal above,=
 it
>> is pointless=2E
>>=20
>> If the goal is to report the temperature only, then hwmon should be use=
d
>> instead=2E
>
>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=2E However other channels might
>only be used for temperature read-out and have no such requirement=2E
>
>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=2E With the trip point=
 the
>> sensor will be set to fire an interrupt at the given trip temperature=
=2E
>>=20
>> IOW, trip points are not optional
>
>for measurement points that are used for thermal throttling /
>mitigation=2E
>
>ChenYu
>