Skip to contentSkip to conversation

thermal driver patch

DISCUSSION Steven J Abner 3 participants 7 messages Aug 17, 2022 – Sep 7, 2022 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

Didn't actually create patch, for you to do and review:

for drivers/thermal/thermal_core.c:397 :

static void update_temperature(struct thermal_zone_device *tz) {
(void)tz;
}

stops kernel dmesg of unused function,
from include/linux/thermal.h:429 :

static inline int thermal_zone_get_temp(
struct thermal_zone_device *tz, int *temp)
{ return -ENODEV; }

If this is a bother, sorry I troubled you.
Per 'Do I have to be subscribed to post to the list?':
I wish to be personally CC'ed the answers/comments posted to the list in response to your posting, please.
Steve

#2 lore raw

Hi--

Quoted 16 lines · Steven J Abner

Didn't actually create patch, for you to do and review:

for drivers/thermal/thermal_core.c:397 :

static void update_temperature(struct thermal_zone_device *tz) {
 (void)tz;
}

stops kernel dmesg of unused function,
from include/linux/thermal.h:429 :

static inline int thermal_zone_get_temp(
 struct thermal_zone_device *tz, int *temp)
{ return -ENODEV; }

Quoted 5 lines

If this is a bother, sorry I troubled you.
Per 'Do I have to be subscribed to post to the list?':
I wish to be personally CC'ed the answers/comments posted to the list in response to your posting, please.
Steve

I haven't seen any such messages, but if this is still a problem, please post:

a. the exact message(s) [copy-paste]
b. how to reproduce the problem
c. what kernel version is causing the problem

Thanks.

Signature · 1 line
~Randy
#3 lore raw
Quoted 2 lines · Randy Dunlap

a. the exact message(s) [copy-paste]
c. what kernel version is causing the problem

[    0.000000] Linux version 5.18.12-051812-generic (kernel@sita) (gcc (Ubuntu 11.3.0-4ubuntu1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38.50.20220629) #202207150942 SMP PREEMPT_DYNAMIC Fri Jul 15 10:10:55 UTC 2022
[    5.244369] thermal thermal_zone0: failed to read out thermal zone (-61)
[    0.000000] Linux version 5.4.204-0504204-generic (kernel@kathleen) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #202207071639 SMP Thu Jul 7 16:59:09 UTC 2022
[    5.207243] thermal thermal_zone0: failed to read out thermal zone (-61)

as to reproduce, can only think of saying: boot up kernel without patched?

additional info that may? help:
I did not trace what calls 'update_temperature', just saw any call to it
will cause message due to it's call to 'thermal_zone_get_temp', which states
no thermal_zone_device should provide or be requesting an update.
It may be that if 'thermal_zone_get_temp' where removed was actual function's
intent, and all instances in this file and other function's use was a case of designer debugging or signaling a deprecated API? That was my intent on saying 'for you to do and review', because it looked like a lot of functions could be
updated to take into account that no device should call functions that start off
by calling 'thermal_zone_get_temp'.
It is more probable that my patch suggestion is wrong and calls to
'update_temperature' are suppose to fail with return -ENODEV always allowing
other calls to 'update_temperature' to fail also. With proposed code, I've not
seen adverse side effects. It just removed dmesg error, but was hoping I would
get lucky and it was the reason for CPUTIN -62C without actually hard work of
finding real reason.

additional dmesg info:
only other 'thermal' are 'thermal_sys' loading governors
smpboot: CPU0: AMD Ryzen 5 2400G with Radeon Vega Graphics (family: 0x17, model: 0x11, stepping: 0x0) from lspci:
Kernel driver in use: k10temp
from lsmod:
nct6775
hwmon_vid
these 2 removed in personal configs, but used in the two ubuntu kernel builds:
wmi
wmi_bmof

Steve

#4 lore raw

Hi Steven,

[adding Rafael, Daniel, linux-pm]

Quoted 1 line
[    5.244369] thermal thermal_zone0: failed to read out thermal zone (-61)

Some driver is returning -ENODATA to the thermal core....

Any suggestions?

Quoted 45 lines · Steven J Abner
Quoted 2 lines · Randy Dunlap

a. the exact message(s) [copy-paste]
c. what kernel version is causing the problem

[    0.000000] Linux version 5.18.12-051812-generic (kernel@sita) (gcc (Ubuntu 11.3.0-4ubuntu1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38.50.20220629) #202207150942 SMP PREEMPT_DYNAMIC Fri Jul 15 10:10:55 UTC 2022 [    5.244369] thermal thermal_zone0: failed to read out thermal zone (-61)

[    0.000000] Linux version 5.4.204-0504204-generic (kernel@kathleen) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #202207071639 SMP Thu Jul 7 16:59:09 UTC 2022 [    5.207243] thermal thermal_zone0: failed to read out thermal zone (-61)

as to reproduce, can only think of saying: boot up kernel without patched?

additional info that may? help:
I did not trace what calls 'update_temperature', just saw any call to it
will cause message due to it's call to 'thermal_zone_get_temp', which states
no thermal_zone_device should provide or be requesting an update.
It may be that if 'thermal_zone_get_temp' where removed was actual function's
intent, and all instances in this file and other function's use was a case of designer debugging or signaling a deprecated API? That was my intent on saying 'for you to do and review', because it looked like a lot of functions could be
updated to take into account that no device should call functions that start off
by calling 'thermal_zone_get_temp'.
 It is more probable that my patch suggestion is wrong and calls to
'update_temperature' are suppose to fail with return -ENODEV always allowing
other calls to 'update_temperature' to fail also. With proposed code, I've not
seen adverse side effects. It just removed dmesg error, but was hoping I would
get lucky and it was the reason for CPUTIN -62C without actually hard work of
finding real reason.

additional dmesg info:
only other 'thermal' are 'thermal_sys' loading governors
smpboot: CPU0: AMD Ryzen 5 2400G with Radeon Vega Graphics (family: 0x17, model: 0x11, stepping: 0x0) from lspci:
Kernel driver in use: k10temp
from lsmod:
nct6775
hwmon_vid
these 2 removed in personal configs, but used in the two ubuntu kernel builds:
wmi
wmi_bmof

Steve

Signature · 1 line
~Randy
#5 lore raw
Quoted 10 lines · Randy Dunlap

Hi Steven,

[adding Rafael, Daniel, linux-pm]

Quoted 1 line
[    5.244369] thermal thermal_zone0: failed to read out thermal zone (-61)

Some driver is returning -ENODATA to the thermal core....

Any suggestions?

Could it be related to this bug?

https://bugzilla.kernel.org/show_bug.cgi?id=201761

Is it possible to give the thermal zone 'type'

Quoted 47 lines · Steven J Abner
Quoted 45 lines · Randy Dunlap
Quoted 2 lines

a. the exact message(s) [copy-paste]
c. what kernel version is causing the problem

[    0.000000] Linux version 5.18.12-051812-generic (kernel@sita) (gcc (Ubuntu 11.3.0-4ubuntu1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38.50.20220629) #202207150942 SMP PREEMPT_DYNAMIC Fri Jul 15 10:10:55 UTC 2022 [    5.244369] thermal thermal_zone0: failed to read out thermal zone (-61)

[    0.000000] Linux version 5.4.204-0504204-generic (kernel@kathleen) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #202207071639 SMP Thu Jul 7 16:59:09 UTC 2022 [    5.207243] thermal thermal_zone0: failed to read out thermal zone (-61)

as to reproduce, can only think of saying: boot up kernel without patched?

additional info that may? help:
I did not trace what calls 'update_temperature', just saw any call to it
will cause message due to it's call to 'thermal_zone_get_temp', which states
no thermal_zone_device should provide or be requesting an update.
It may be that if 'thermal_zone_get_temp' where removed was actual function's
intent, and all instances in this file and other function's use was a case of designer debugging or signaling a deprecated API? That was my intent on saying 'for you to do and review', because it looked like a lot of functions could be
updated to take into account that no device should call functions that start off
by calling 'thermal_zone_get_temp'.
 It is more probable that my patch suggestion is wrong and calls to
'update_temperature' are suppose to fail with return -ENODEV always allowing
other calls to 'update_temperature' to fail also. With proposed code, I've not
seen adverse side effects. It just removed dmesg error, but was hoping I would
get lucky and it was the reason for CPUTIN -62C without actually hard work of
finding real reason.

additional dmesg info:
only other 'thermal' are 'thermal_sys' loading governors
smpboot: CPU0: AMD Ryzen 5 2400G with Radeon Vega Graphics (family: 0x17, model: 0x11, stepping: 0x0) from lspci:
Kernel driver in use: k10temp
from lsmod:
nct6775
hwmon_vid
these 2 removed in personal configs, but used in the two ubuntu kernel builds:
wmi
wmi_bmof

Steve

Signature · 5 lines
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
#6 lore raw
Quoted 5 lines · Daniel Lezcano

Could it be related to this bug?

https://bugzilla.kernel.org/show_bug.cgi?id=201761

Is it possible to give the thermal zone 'type'

Did verify that that my thermal_zone0 is my wifi:
used lm-sensor and cat /sys/class/thermal/thermal_zone0/temp along with wifi load to heat to temps different then others to check outputs. The above mentioned bug page could have lead to this, I can't say or track.

Prefix the following with I'm not an expert, just info provider:

My guess is not supposed to be calling function during initial kernel loading, based on following:

from thermal_core.c:
18:
#include <linux/thermal.h>

397:
static void update_temperature(struct thermal_zone_device *tz)

{
	int temp, ret;

	ret = thermal_zone_get_temp(tz, &temp);
	if (ret) {
		if (ret != -EAGAIN)
			dev_warn(&tz->device,
				 "failed to read out thermal zone (%d)\n",
				 ret);
		return;
	}

	mutex_lock(&tz->lock);
	tz->last_temperature = tz->temperature;
	tz->temperature = temp;
	mutex_unlock(&tz->lock);

	trace_thermal_temperature(tz);

	thermal_genl_sampling_temp(tz->id, temp);
}

from linux/thermal.h:
429:
static inline int thermal_zone_get_temp(
struct thermal_zone_device *tz, int *temp)
{ return -ENODEV; }

compiler should then read:
static void update_temperature(struct thermal_zone_device *tz)

{
	int temp, ret;

	ret = -ENODEV;
	if (ret) {
		if (ret != -EAGAIN)
			dev_warn(&tz->device,
				 "failed to read out thermal zone (%d)\n",
				 ret);
		return;
	}

however did find with extra search:
in /drivers/thermal/thermal_helpers.c:
78:
int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp) and
115:
EXPORT_SYMBOL_GPL(thermal_zone_get_temp);

so is this bootup vs system hand off?
where bootup call thermal_zone_get_temp() shouldn't occur?

Steve

#7 lore raw

Additional info:
After an automatic overnight suspend, from dmesg:

[23668.033055] thermal thermal_zone0: failed to read out thermal zone (-61)
[23668.033197] PM: suspend exit

So is it possible that driver iwlwifi is built with 'return -ENODEV;' into its init/reset code?
Also this code from kernel 5.18.19 instead of 5.18.12 initial report messaging.

Steve