summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorRicardo Neri <ricardo.neri-calderon@linux.intel.com>2026-09-24 19:33:20 -0700
committerGuenter Roeck <linux@roeck-us.net>2026-09-25 07:03:09 -0700
commite463cd582ca125e359ad1a66cb076434c14638b2 (patch)
tree907358d6da7d77b0871116e5d4b062e0885dd771 /tools/lib/python/kdoc/python_version.py
parenteddb0aaacce4baa9d8176eb2f4bd9e99e867f8fc (diff)
downloadlinux-next-e463cd582ca125e359ad1a66cb076434c14638b2.tar.gz
linux-next-e463cd582ca125e359ad1a66cb076434c14638b2.zip
hwmon: (coretemp) Refresh the temperature on the first read
show_temp() reads the status MSR only when the cached temperature is older than one second. Commit 5c0e64dde80f ("hwmon: (coretemp) Remove obsolete temp_data->valid") dropped the tdata->valid check that used to force the very first read, leaving that comparison as the only trigger. A never-updated temp_data carries a zero timestamp, which does not look stale on 32-bit kernels: jiffies starts 300 seconds short of wrapping, so the comparison stays false until jiffies wraps and passes HZ. For the first 301 seconds of uptime temp%d_input reports the zero left by the allocator rather than the CPU temperature. 64-bit kernels are unaffected: jiffies starts at a positive value there and does not wrap. Backdate the timestamp when the temperature data is allocated. One jiffy older than the caching interval is stale under either word size, and the first refresh overwrites it. Fixes: 5c0e64dde80f ("hwmon: (coretemp) Remove obsolete temp_data->valid") Cc: stable@vger.kernel.org Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Link: https://patch.msgid.link/20260924-coretemp-temp-fault-v1-1-1884f0ff97d5@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions