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

[Ricardo Neri <ricardo.neri-calderon@linux.intel.com>]

On Fri, Sep 25, 2026 at 02:23:49PM -0700, Guenter Roeck wrote:
> 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.

Then it seems that the fault attribute is redundant.

> 
> 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.

I see. I will implement returning -ENODATA and drop the temp%d_fault.

Best,
Ricardo