Re: [PATCH 0/3] hwmon: (coretemp) Report unreliable temperature readings

[Guenter Roeck <linux@roeck-us.net>]

On Thu, Sep 24, 2026 at 07:33:19PM -0700, Ricardo Neri wrote:
> Hi,
> 
> Intel CPUs indicate in IA32_[PACKAGE]_THERM_STATUS whether the digital
> thermal readout they expose is valid. coretemp deliberately ignores that
> indication, for the reason given in commit bf6ea084ebb5 ("hwmon:
> (coretemp) Do not return -EAGAIN for low temperatures"): some CPUs clear
> it while the temperature is too low to be measured, and the value reported
> in that state is more useful to userspace than an error would be.
> 
> The consequence is that userspace cannot distinguish a genuinely low
> temperature from one the CPU could not measure. This series exposes the
> indication through the standard hwmon temp%d_fault attribute, leaving
> temp%d_input exactly as it is.
> 
> One user-visible effect is worth mentioning: sensors(1) prints FAULT in
> place of the temperature when temp%d_fault reads 1. On a CPU that clears
> the valid bit at low temperature, that core stops showing a number in the
> default output, although sensors -u and -j still report it, as does
> anything that reads temp%d_input from sysfs directly. A driver-custom
> attribute name would avoid this, but would be invisible to generic tools.
> Reporting the condition through the documented attribute looks like a
> better option, but please say if you prefer otherwise.

I think it would be _much_ better to return -ENODATA for invalid readings.
This isn't really a fault, after all. The sensor is not defective,
it just can not provide valid data.

With -ENODATA the sensors command reports N/A for the temperature
measurement, which I also think would be better than reporting FAULT.

Thanks,
Guenter