linux-kernel - RE: [PATCH 2/6] thermal: of: Export non-devres helper to register/unregister thermal zone

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <TY3PR01MB1134683B8AA347AD624E4F17486E92@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Thu, 30 Jan 2025 17:47:20 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>, Claudiu.Beznea
	<claudiu.beznea@...on.dev>
CC: "rafael@...nel.org" <rafael@...nel.org>, "rui.zhang@...el.com"
	<rui.zhang@...el.com>, "lukasz.luba@....com" <lukasz.luba@....com>,
	"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"geert+renesas@...der.be" <geert+renesas@...der.be>, "magnus.damm@...il.com"
	<magnus.damm@...il.com>, "mturquette@...libre.com" <mturquette@...libre.com>,
	"sboyd@...nel.org" <sboyd@...nel.org>, "p.zabel@...gutronix.de"
	<p.zabel@...gutronix.de>, "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-clk@...r.kernel.org"
	<linux-clk@...r.kernel.org>, Claudiu Beznea
	<claudiu.beznea.uj@...renesas.com>
Subject: RE: [PATCH 2/6] thermal: of: Export non-devres helper to
 register/unregister thermal zone

Hi Daniel Lezcano,

> -----Original Message-----
> From: Daniel Lezcano <daniel.lezcano@...aro.org>
> Sent: 30 January 2025 17:32
> Subject: Re: [PATCH 2/6] thermal: of: Export non-devres helper to register/unregister thermal zone
> 
> On 30/01/2025 11:33, Biju Das wrote:
> > Hi Daniel Lezcano,
> >
> >> -----Original Message-----
> 
> [ ... ]
> 
> >>>> I've been through the driver before responding to this change. What
> >>>> is the benefit of powering down / up (or clock off / on) the
> >>>> thermal sensor when reading the temperature ?
> >>>>
> >>>> I can understand for disable / enable but I don't get for the
> >>>> classic usage where a governor will be reading the temperature regularly.
> >>>
> >>> I tried to be as power saving as possible both at runtime and after
> >>> the IP is not used anymore as the HW manual doesn't mentioned
> >>> anything about accuracy or implications of disabling the IP clock at runtime.
> >>> We use similar approach (of disabling clocks at runtime) for other
> >>> IPs in the RZ/G3S SoC as well.
> >>>
> >>>>
> >>>> Would the IP need some cycles to capture the temperature accurately
> >>>> after the clock is enabled ?
> >>>
> >>> There is nothing about this mentioned about this in the HW manual of
> >>> the RZ/G3S SoC. The only points mentioned are as described in the driver code:
> >>> - wait at least 3us after each IIO channel read
> >>> - wait at least 30us after enabling the sensor
> >>> - wait at least 50us after setting OE bit in TSU_SM
> >>>
> >>> For this I chose to have it implemented as proposed.
> >>
> >> IMO, disabling/enabling the clock between two reads through the pm
> >> runtime may not be a good thing, especially if the system enters a thermal situation where it has
> to mitigate.
> >
> > Just a question, You mean to avoid device destruction due to high
> > temperature?? Assuming disabling the clk happens when the temp reaches
> > the boundary and re-enabling of the clk after a time(which involves monitoring the CLK ON bit after
> enabling it, or a run time enable failure happens), where it exceeds the threshold??
> 
> 
> Well, I have some comments with the device tree thermal configuration which may answer your question
> but I'll wait for Claudiu to check the temperature read comparison without rounding to 0.5°C
> 
> What I meant is if the temperature read is inaccurate, the mitigation will be inaccurate too. It may
> not reach the critical temperature but it is possible the performance could be impacted negatively
> under thermal stress.

Thanks for the explanation. 

I thought you meant " disabling/enabling the clock between two reads through the pm
runtime may not be a good thing" under stress/hot condition, temperature raises, and
in those corner cases if runtime PM fails, then we cannot read temperature and
we cannot take any corrective action.

Cheers,
Biju