Fujitsu Siemens sensor HERMES

Reinhard Nissl rnissl at gmx.de
Sun Jan 11 15:06:08 CET 2004


Hi,

Jean Delvare wrote:

>>Now as kernel 2.6.0 is released, I feel the need to port fscher to
>>2.6.0. I've already started today, but didn't have success so far.
> 
> That would be great to have a ported driver for sure :)

[snip]

>>Attached you'll find what I've done so far. Please send me your
>>comments and hints.
> 
> I'd suggest you first read Documentation/i2c/porting-clients as found in
> Linux 2.6.1-rc1 and later. That's a document I wrote about porting chip
> drivers from linux 2.4 to linux 2.6. I believe that almost all questions
> you'd ask are answered there. If you don't mind, I'll take a look at
> your code after you read that document and applied its contents to
> your driver.

I had a look at it.

> If you have questions that are not answered there, ask. If you want
> things to be added to the document, tell me.

How would you name the file, where the chip revision will be made available 
(rev, revision, ...)? Should it be made availble?

HERMES has a 'Global event status register'. It's something like alarms. E. g. 
bit 0 tells you, that there is a 'Global fan fault event'. Which fan is faulty 
must be determined by looking at the fan status registers, where bit 2 tells 
one, that the fan is faulty.

Is it ok to create fan_status1...3 files, containing the fan's status register 
value?

Concerning alarms: what do you mean by comparator mode?

HERMES e. g. signals 'Global fan fault event' as long as any of the fan status 
registers signals 'Fan fault'. Clearing all fan status registers (by writing 
this bit2 to 1) will finally have HERMES clear the 'Global fan fault event' 
(Globel event status register bit 0). Is this the expected behaviour?

One of the event bits is called 'Global software event'. This bit can be set 
and cleared by writing bit 0 of the global control register to 1 respectively 
0. Is it ok to supply a file named 'control' for this purpose?

Concerning beep*: I assume, that the hardware must support some way of making 
noise, when an alarm occurs. This is not the case for HERMES.

Concerning in_input*: HERMES only tells me unscaled values for +5.0V, +12.0V 
and +3.0V for the backup battery. In the current release, I used dmidecode to 
get the scaling factors and offsets from my mainboard and used them to finally 
hardcode scaling of the supplied values.

What shall I do for kernel 2.6.x? Which numbers shall I append to in_input? 
Where shell I put the battery voltage? Is there a way to read the dmi values 
from withing the fscher module?

Concerning temp*: HERMES supplies a 'Sensor status register' for each 
temperature sensor, where it signals over temperature respectively sensor 
hadrware faults (similar to fan_status). Is it ok to supply temp_status files?

Finally the watchdog:
I'd supply a 'watchdog_control' file, which is used e. g. to retrigger the 
watchdog. Then I would supply a 'watchdog_status' file, which tells you that a 
  system reset due to a watchdog event has occured. And last but not least a 
file 'watchdog_preset' where to set the watchdog time.

Is this all ok?

> Please note that limits initialization has been removed from all
> drivers since it sometimes caused much trouble, and the same can be
> achived with "sensors -s". That's not a 2.6 porting issue, but that's
> something new since you wrote your original driver.

Can you tell me more, if it is still of interest?

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de




More information about the lm-sensors mailing list