"failed to read out thermal zone" for wifi thermal zone

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

--- Comment #50 from Zhang Rui ([email protected]) --- (In reply to Daniel Lezcano from comment #49)

Quoted 5 lines

This is clearly spotted by the error happening at the end of the thermal_zone_device_register() function which calls thermal_zone_device_update() at the end: the thermal zone is registered
before the sensor is initialized.

thermal_zone_device_update() can handle a disabled thermal zone now. So if we
flag the thermal zone as disabled during registration, thermal_zone_device_update() is a no-op.

This just means it is doable technically.
But let's understand why the current thermal APIs
(register/unregister) can not
fit the current problem first.

Quoted 7 lines

That is the reason why I think the driver is not doing the right thing and
should take care of registering/unregistering the thermal zone when the
sensor (aka firmware code) can operate, otherwise we create an empty sensor
device which is wrong.

Okay, I found the previous conversation with Luciano Coelho, the iwlwifi
maintainer.

"This issue has been know by us for a while now and we also had users complain
about it, but at the time there was nothing we could do. The reason for
registering before we can actually provide the temperature is because the wifi
interface may go up and down many times and we didn't want the userspace to
keep having to set values again."

Luca,
can you give more details about what the userspace does for the iwlwifi thermal
zone, and how often the iwlwifi interface becomes avaialble/unavailable?

We want to fully understand the drawbacks of doing thermal register/unregister.

Quoted 8 lines

In addition, userspace programs may not be aware of the thermal zone mode
and continue reading the temp file with the same ENODATA error. Especially
when they read the temp from /sys/class/hwmon where the disabled state is
not available.

I agree. We can only prevent access of a disabled thermal zone from kernel, but
accessing via sysfs can still trigger this error.

But the kernel failure is what this bug report mainly complains. And if users read the temp when the wifi interface is down, it will get an
error, I don't think there is a problem.
Plus, we can add the tz->mode check in sysfs attribute callbacks, and give an
extra warning of "accessing-to-a-disabled-thermal-zone".