From: Landry Breuil Subject: upd(4): fix RunTimeToEmpty for EATON upses To: tech@openbsd.org Date: Sun, 9 Feb 2025 10:17:56 +0100 hi, comeback of a diff i still had around, and has been tested by various ppl on 3 distinct models of eaton upses which report a broken (eg huge) value for RunTimeToEmpty. i dont remember the exact details of my reading of the spec and the sysutils/nut code, but if we read 4 bytes for RunTimeToEmpty, then the actual value is in the leftmost bytes, so right-shifting / dividing the adjust factor by 256 gives me a value that matches the value reported by nut. i pondered doing the right-shifting after reading the actual hdata to make sure the raw value read was within 'sensible' bounds, but i wouldn't know how to define those.. advices welcome. "If the value is above 3h then it doesnt make sense and right-shift should apply" ? i can also make it specific to eaton vendor, that just requires more plumbing to propagate the hid vendor here and there.. without the diff: hw.sensors.upd0.timedelta0=227940.000000 secs (RunTimeToEmpty), OK (systat sensors) upd0.timedelta0 2.638 days OK RunTimeToEmpty with the diff: hw.sensors.upd0.timedelta0=890.390625 secs (RunTimeToEmpty), OK (systat sensors) upd0.timedelta0 14.840 min OK RunTimeToEmpty i'd like this diff to make 7.7, so oks are welcome. tests on non-eaton UPSses are of course welcome, but it seems so far only some eaton reports this sensor on 4 bytes. Landry Index: upd.c =================================================================== RCS file: /cvs/src/sys/dev/usb/upd.c,v diff -u -r1.33 upd.c --- upd.c 1 Dec 2024 09:05:05 -0000 1.33 +++ upd.c 9 Feb 2025 08:55:10 -0000 @@ -421,6 +421,8 @@ case HUB_RUNTIMETO_EMPTY: /* spec says minutes, not seconds */ adjust = 1000000000LL; + if (len == 4) + adjust = adjust >> 8; break; default: adjust = 1; /* no scale adjust */