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

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

On Fri, Sep 25, 2026 at 11:21:58AM -0700, Ricardo Neri wrote:
> On Thu, Sep 24, 2026 at 07:37:18PM -0700, Guenter Roeck wrote:
> > 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.
> 
> Thank you for your feedback and for applying the other two patches!
> 
> Thank you for your feedback anf for applying the first two patches!
> 
> Userspace has seen a number in temp%d_input for over 12 years, and with
> this change it would get an error on CPUs that clear the valid bit. I can
> certainly implement returning -ENODATA; I just want to confirm you don't
> see this as an issue for userspace.
> 

Userspace should be able to handle error returns. That is not an ABI change.
Even if the fault attribute was implemented, trying to read the temperature
should still return an error.

On the other side, claiming that the sensor is faulty is, in my opinion,
just wrong. It is not faulty, it just does not return valid data.

Guenter