Fujitsu Siemens sensor HERMES
rnissl at gmx.de
Sun Jan 11 21:32:30 CET 2004
Jean Delvare wrote:
>>Well, as stated above, you have to write 4 to the fan status register,
>>which will in turn clear bit 2 of the fan status register. If no more
>>fan status registers indicate a fan failure, the 'Global fan fault
>>event' will clear too (simple OR-logic, as you mentioned above).
> Writing a 1 to the bit so that it is reset is a strange idea, isn't it?
Well, how would you indicate the bit to clear otherwise?
[ snip: global software event ]
>>Which suffixes shall I choose for the unscaled 5 V and 12 V voltages,
>>and especially, which one for the 3 V backup battery?
> I don't see any difficulty here. They are in0, in1 and in2. We never
> give names to the channels, only number. Labels are set with
Ok, so everything is like before, besides the values beeing unscaled.
[ snip: voltage scaling ]
>>>Go for it. Strange how they split their alarms in so many different
>>>registers. Usually we combine all of them into a single, 32-bit max
>>>value (the "alarms" file) but it looks like the Hermes has just too
>>>many of them do to so. Unless only a few bits are used in each
>>True. Each fan status has just one bit while each temperature sensor
>>>the total number of alarm bits is less than 32, you should consider
>>>combining them all into a single value.
>>Well, all status flags would be no more than 32. Shall I therefore
>>drop fan_status*, temp_status* and watchdog_status and put them all
>>together into alarms?
> That's what I was suggesting, but...
>>Clearing a certain fan status bit would then require to calculate a
>>proper value. This value must then be written into alarms to get the
>>bit cleared. Writing -1 to alarms would therefore clear all clearable
>>status bits. The others would then get updated by HERMES' internal
> ...the fact that you could write to this file would be something
> unusual. And it would for sure make your code more complex, if not
> unreadable (unless you document it a lot). That might not be worth it,
> especially since the benefit would be thin. It is very interesting to
> respect file namings when the name is enough for a third party software
> to use the value. This isn't the case with alarms anyway, since the
> meaning of each bit is driver-dependant. So in the end, if having
> different files is more convenient, go for it.
I think so, too.
> I'd like to hear Greg (and possibly others) about this though.
BTW: I'm not on the ML.
>>The drawback is, that one has to fiddle around with large powers of
>>two. This makes it more complicated for a human beeing to see at a
>>glance, where the problem is.
> This is the way it is done in all other drivers. Users are not supposed
> to read raw values from /sys or /proc. They run sensors or any other
> piece software which decode the alarms file for them. So that's not a
> valid reason IMHO.
Ok, but then I should complete the output of sensors for fscher and also
include alarms and watchdog.
>>So, with a single 'sensors -s' instruction one could for example set
>>all the pwm* values for the fans?
>>Currently, I use
>> echo 4 2 > /proc/sys/dev/sensors/fscher*/fan1
>> echo 4 1 > /proc/sys/dev/sensors/fscher*/fan2
>> echo 4 1 > /proc/sys/dev/sensors/fscher*/fan3
> You like reading and writing to /proc files directly, don't you? ;)
Maybe, I was just to lazy to look for a different solution. From coding the
module, I knew that it would work that easy ;-).
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de
More information about the lm-sensors