[lm-sensors] issue with clearing alarms

[Jim Cromie]

Jean Delvare wrote:
> Hi Jim,
>
>   
> To me, "new data not yet read" simply means that at least one sampling
> cycle was completed since our last read. There's nothing wrong with
> that, as the chip samples its inputs continuously and we only read the
> values from times to times.
>
>   


Looking again, I see a point of confusion at least, and a possible problem.
It may be one of interpretation, but is worth checking, and possibly 
documenting.

The *not-yet-read* property pertains to the scan done by update_device(),
since thats what reads all sensors the driver supports.
But its easy to misconstrue not-yet-read as a property on the individual 
alarms.

More importantly, any single read of any property will clear unrelated 
alarms.
Let me demonstrate:

1- raise then lower the min setting, then check the alarm,
    which is (properly) on.  A 2nd read shows it cleared. (also proper)

soekris:/sys/devices/platform/i2c-9191/9191-6620# echo 1500 > in8_min
soekris:/sys/devices/platform/i2c-9191/9191-6620# echo 1400 > in8_min
soekris:/sys/devices/platform/i2c-9191/9191-6620# cat in8_min_alarm
2
soekris:/sys/devices/platform/i2c-9191/9191-6620# cat in8_min_alarm
0

2- repeat raise & lower, then read an *unrelated* attr
    now 1st read of in8_min_alarm shows 0, the alarm state has been *missed*

soekris:/sys/devices/platform/i2c-9191/9191-6620# echo 1500 > in8_min
soekris:/sys/devices/platform/i2c-9191/9191-6620# echo 1400 > in8_min
soekris:/sys/devices/platform/i2c-9191/9191-6620# cat in2_min_alarm
0
soekris:/sys/devices/platform/i2c-9191/9191-6620# cat in8_min_alarm
0

3- redo test 2, this time reading a setting, then reading alarm.  its 
off, should be on.
    this time, its a readback of config value, which doensnt *need* to 
trigger a scan,
    but does cuz its simpler (I guess)

soekris:/sys/devices/platform/i2c-9191/9191-6620# echo 1500 > in8_min
soekris:/sys/devices/platform/i2c-9191/9191-6620# echo 1400 > in8_min
soekris:/sys/devices/platform/i2c-9191/9191-6620# cat in8_min
1394
soekris:/sys/devices/platform/i2c-9191/9191-6620# cat in8_min_alarm
0




IOW, 2 reads of any 2 sysfs-files, separated by this much time, will 
reset the alarm,
even though userspace has never seen the alarm.

    if (time_after(jiffies, data->last_updated + HZ * 2) || !data->valid) {
        dev_dbg(&client->dev, "Data update\n");




So, with the usual caveats (Ive done something wrong, immature code, etc)
I see a few possibilities:

1 - Document the fact - tell users not to do that.
    this isnt unreasonable, and far simpler..
2 - sensors-deamon locks the directory to preclude loss of alarms (is 
this possible ? bad idea ?)
3 - dunno