[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <30c38867-78b0-d3a1-ffcf-9612a7befc3a@squareup.com>
Date: Thu, 20 Jan 2022 11:32:01 -0800
From: Benjamin Li <benl@...areup.com>
To: Amit Kucheria <amitk@...nel.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Zhang Rui <rui.zhang@...el.com>,
Linux PM list <linux-pm@...r.kernel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] drivers: thermal: tsens: respect thermal_device_mode
in threshold irq reporting
On 1/19/22 4:33 PM, Bjorn Andersson <bjorn.andersson@...aro.org> wrote:
> Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
Thanks!
On 1/20/22 3:40 AM, Amit Kucheria wrote:
>> + dev_dbg(priv->dev, "[%u] %s: TZ update trigger (%d mC)\n",
>> + hw_id, __func__, temp);
>> + thermal_zone_device_update(s->tzd, THERMAL_EVENT_UNSPECIFIED);
>> + } else {
>> + dev_dbg(priv->dev, "[%u] %s: TZ update trigger (%d mC) skipped as zone disabled\n",
>
> Hmm. I don't like the fact that these messages won't be visible to
> users in dmesg unless they're debugging. This change puts the SoC in a
> potentially unsafe state. Perhaps we should print a ratelimited
> message in the logs that we're operating outside safety limits?
That seems fine, I'll change to dev_info_ratelimited and make the message
a bit scarier.
>
>> + hw_id, __func__, temp);
>> + }
>> } else {
>> - dev_dbg(priv->dev, "[%u] %s: no violation: %d\n",
>> - hw_id, __func__, temp);
>> + dev_dbg(priv->dev, "[%u] %s: no violation: %d\n", hw_id, __func__, temp);
>
> Get rid of this hunk, it is unrelated to the above change.
Will do.
>
>> }
>>
>> if (tsens_version(priv) < VER_0_1) {
>> --
>> 2.17.1
>>
Powered by blists - more mailing lists