summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorTom Verdonck <tom.verdonck@inspiral.be>2026-09-25 20:23:22 +0200
committerGuenter Roeck <linux@roeck-us.net>2026-09-25 20:25:46 -0700
commit56c1d32323e773b8b927316f8beeae9238576335 (patch)
treefc03769d0ced421400b4d988e9c6a904d7a125a1 /tools/lib/python/kdoc/python_version.py
parente463cd582ca125e359ad1a66cb076434c14638b2 (diff)
downloadlinux-next-56c1d32323e773b8b927316f8beeae9238576335.tar.gz
linux-next-56c1d32323e773b8b927316f8beeae9238576335.zip
hwmon: (tmp102) Fix jiffies wraparound in conversion-ready check
tmp102 records a one-shot deadline in ->ready_time at probe (and resume) and, on every temperature read, refuses the read with -EAGAIN while time_before(jiffies, ready_time) is true, in order to skip the first ~35 ms conversion. ->ready_time is an unsigned long compared with time_before(), whose signed difference is only meaningful while the two values are within LONG_MAX jiffies of each other. Because ->ready_time is set once and never refreshed, jiffies keeps advancing away from it, and after 2^31 jiffies the difference flips sign. On a 32-bit HZ=100 kernel that happens ~248.5 days after boot: time_before() then permanently reports "not ready" and the driver returns -EAGAIN on every read, without ever touching the sensor, until the next reboot. Store the deadline as a 64-bit jiffies value and compare it with get_jiffies_64()/time_before64(), which does not wrap in any practical uptime. Fixes: 3d8f7a89a197 ("hwmon: (tmp102) Improve handling of initial read delay") Cc: stable@vger.kernel.org Signed-off-by: Tom Verdonck <tom.verdonck@inspiral.be> Link: https://patch.msgid.link/2952f070f82913aea96eec25d28008d3b9058656.1790358356.git.tom.verdonck@inspiral.be 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