Messages in this thread | | | Date | Mon, 6 Apr 2020 12:17:51 -0700 | From | Guenter Roeck <> | Subject | Re: hwmon: drivetemp: bogus values after wake up from suspend |
| |
On Mon, Apr 06, 2020 at 06:23:01PM +0200, Holger Hoffstätte wrote: > > I've been giving the drivetemp hwmon driver a try and am very happy > with it; works right away and - much to my surprise - doesn't wake up > HDDs that have gone to sleep. Nice! > > I did notice one tiny thing though: after waking up from suspend, my SSD > (Samsung 850 Pro) reports a few initial bogus values - suspiciously -128°, > which is definitely not the temperature in my office. While this is more > a cosmetic problem, it cramps my monitoring setup and leads to wrong graphs. > Can't have that! > > So I looked into the source and found that the values are (understandably) > passed on unfiltered/uncapped. Since it's unlikely any active device has > operating temperature below-zero, I figured the laziest way is to cap the > value to positive: > > diff -rup a/drivers/hwmon/drivetemp.c b/drivers/hwmon/drivetemp.c > --- a/drivers/hwmon/drivetemp.c 2020-04-02 08:02:32.000000000 +0200 > +++ b/drivers/hwmon/drivetemp.c 2020-04-06 18:13:04.892554087 +0200 > @@ -147,7 +147,7 @@ static LIST_HEAD(drivetemp_devlist); > #define INVALID_TEMP 0x80 > #define temp_is_valid(temp) ((temp) != INVALID_TEMP) > -#define temp_from_sct(temp) (((s8)(temp)) * 1000) > +#define temp_from_sct(temp) (max(0, ((s8)(temp)) * 1000)) > static inline bool ata_id_smart_supported(u16 *id) > { > > The assumption is of course *theoretically* wrong since some > equipment might indeed operate in negative C°. One way might be > to use the device's "low" operating point first, but then that > might not be available and we'd be back to capping to 0. > I'm open to other suggestions. :) >
I think 0 is't much better than -128, unless your office is somewhere in the Arctic. I'll have to loook up the spec, but I think -128 may mean "no data". Maybe we can return something like -ENODATA in that case.
Guenter
| |