definitely should not load.
Also fixed GL520 detection bug. Some other bugs are probably still there.
The report is generated using a very intricate data structure. There
can easily be hidden problems. Just test, test, test :-)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@255 7894878c-1315-0410-8ee3-d5d059ff63e0
It is already very usable, but not quite finished. The final product will
also collect the needed drivers, and output them as modprobe lines and/or
in other formats.
The most important thing right now is to test where possible the detection
algorithms.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@252 7894878c-1315-0410-8ee3-d5d059ff63e0
Well, it still takes some tinkering, and I need to create a user-interface.
If you want to play with it already:
* Uncomment the line beneath test, and put the adapter number (as
corresponding with /dev/i2c-*) behind it as argument;
* It only detects LM78, LM78-J, LM79 and LM80 at of this moment;
* Only LM75 detection is really tested, as I don't have my LM78 connected
to the SMBus.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@250 7894878c-1315-0410-8ee3-d5d059ff63e0
bug (checked out as one user, and commiting as another to the same checked
out project?). Anyways, things seem to be OK now (I hope!).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@249 7894878c-1315-0410-8ee3-d5d059ff63e0
It compiles now cleanly against kernel 2.0.36; I checked, double-checked and
cross-checked.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@247 7894878c-1315-0410-8ee3-d5d059ff63e0
It needs to be expanded a bit and tested, but this means I can start to
write chip detection routines from Perl!
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@238 7894878c-1315-0410-8ee3-d5d059ff63e0
All our own code (ie. anything not in the i2c directory) compiles now without
warnings, even with WARN=1 (which sets -Wall -Wstrict-prototypes -Wshadow
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wnested-externs
-Winline). There is one exception: the lex code (conf-lex.l) complains about
unused functions. That's flex' fault, not ours!
The i2c code still emits many warnings with the above flags; that's Simon's
problem.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@233 7894878c-1315-0410-8ee3-d5d059ff63e0
features of it:
- As long as the 'sensors' program works correctly, healthd.sh is compatible
with any hardware.
- Very low loading. Just sleeps (like me) most of the time.
- Easily customizable (very simple and short script).
Todo's/wants:
- Syslogging? I couldn't figure out how to syslog from bash shell (yet).
- After one test, it failed to be automatically 'spawned' from a rc.local
script. I did "healthd.sh &", but that didn't seem to work. Ideas?
- a history utility for making pretty plots and such.
- Written in 'C' for better functionality and efficiency?
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@229 7894878c-1315-0410-8ee3-d5d059ff63e0
(from the Greek meaning 'shortcoming').
A word electrical engineers like me learn to know and love.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@223 7894878c-1315-0410-8ee3-d5d059ff63e0
I am trying to create a more-or-less standard documentation format for
doc/chips/* files. I am not quite satisfied with the lm75 and lm78 docs
yet, but it is starting to come. Basically, I want as much information
in it as possible, and to generate most of it automatically. But that is
harder than I though it would be.
Also, a small library bugfix (class problem) and a doc-features fix.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@210 7894878c-1315-0410-8ee3-d5d059ff63e0
This program automatically documents the available features for each chip.
Basically, it translates the data in lib/chips.c back to a human-readable
format.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@208 7894878c-1315-0410-8ee3-d5d059ff63e0
Frodo Looijaard