[lm-sensors] Howto handle alarms which need to be reset?

[Jean Delvare]

Hi Hans,

Sorry for the late reply.

On Thu, 05 Jul 2007 18:01:44 +0200, Hans de Goede wrote:
> Replying to my own mails seems to become a bad habbit of mine.

Well, at least that makes always at least one person who replies to
your posts ;)

> I think I've solved this I've done some reverse engineering on the fscher using 
> i2cdump and i2cset and I've found the following undocumented registers (there 
> are more undocumented ones, but for these I've now found the meaning)
> 
> 0x73 temp1_auto_point1_temp (unit degrees celcius + 128, just like temp1_input)
> 0x75 temp1_auto_point2_temp (unit degrees celcius + 128, just like temp1_input)
> 0x76 temp1_max              (unit degrees celcius + 128, just like temp1_input)
> 
> This I'm close to 100% sure off.
> 
> and:
> 0x83 temp2_auto_point1_temp (unit degrees celcius + 128, just like temp2_input)
> 0x86 temp2_max              (unit degrees celcius + 128, just like temp2_input)
> 
> Notice that 0x85 is missing, its 00 and cannot be written too, perhaps this has 
> todo with the fact that my system has only one fan lowering 0x83 below temp2 
> does make that one fan increase its speed. I guess 0x85 being 0 and 0x83 
> influencing the same fan as which is controlled by the temp1 autopoints is 
> regulated through the flags in 0x84, which are different from those in 0x74, I 
> have no idea what these flags mean however.
> 
> and I think:
> 0x93 temp3_auto_point1_temp (unit degrees celcius + 128, just like temp3_input)
> 0x96 temp3_max              (unit degrees celcius + 128, just like temp3_input)
> 
> I say I think as my system doesn't have a third temp sensor connected, but they 
> both have pretty realistic value for a system / case temp sensor, also notice 
> the regular intervals between all the addresses.
> 
> Unfortunately I do not have access to an fscpos machine and thus cannot check 
> if the same is true for the fscpos.
> 
> How to move forward now?
> 
> My plan is to write an updated fscher patch which adds tempX_max rw sysfs 
> attributes, and use those to automatically reset the alarm.

Sounds like a good plan.

> I'm also considering adding autopoints sysfs attributes, but only for those 
> autopoints which do not read 0, as the chip seems to have the ability to 
> disable the 2nd autopoint for each temp and when it is disabled it reads as 0.
> 
> What do you think of adding the autopoints (I'm certain about the ones for 
> temp1, they behave 100% as expected)?

Please make it a separate patch. As these registers are undocumented,
you need to find testers before pushing such a patch upstream.

-- 
Jean Delvare