diff options
| author | Tom Verdonck <tom.verdonck@inspiral.be> | 2026-09-25 20:23:22 +0200 |
|---|---|---|
| committer | Guenter Roeck <linux@roeck-us.net> | 2026-09-25 20:25:46 -0700 |
| commit | 56c1d32323e773b8b927316f8beeae9238576335 (patch) | |
| tree | fc03769d0ced421400b4d988e9c6a904d7a125a1 /tools/lib/python/kdoc/python_version.py | |
| parent | e463cd582ca125e359ad1a66cb076434c14638b2 (diff) | |
| download | linux-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
