default. Now uses libsensors. Ripped the display formatting code from
sensors (with some modification) but needless to say I've only tested
a single chip. Doesn't support alarms yet. With a bit of work, could
share the display formatting code with sensors so just one source needs
updating. Compiles on my machine.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@661 7894878c-1315-0410-8ee3-d5d059ff63e0
Reasons varied from typos (_ instead of -) to static declarations that
should have been extern.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@646 7894878c-1315-0410-8ee3-d5d059ff63e0
<linux/version.h> was not included (it was automatically
included by <linux/module.h> when a module, but that is not good
enough of course...)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@644 7894878c-1315-0410-8ee3-d5d059ff63e0
sensors-detect detection is now complete; I think nothing else needs
to be done in the tree?!? (except documentation of course)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@643 7894878c-1315-0410-8ee3-d5d059ff63e0
* Improved monitoring of /proc directories
Instead of doing:
proc_bus_i2c->fill_inode = &monitor_bus_i2c;
void monitor_bus_i2c(struct inode *inode, int fill)
{
if (fill)
MOD_INC_USE_COUNT;
else
MOD_DEC_USE_COUNT;
}
you can now simply set:
proc_bus_i2c->owner = THIS_MODULE;
and this is just as good!
* An old 2.3 problem seemingly never was resolved yet: instead of using
a *wait_queue directly, you have to use a wait_queue_head_t and
initialize it properly:
#if (LINUX_VERSION_CODE < 0x020301)
static struct wait_queue *pcf_wait = NULL;
#else
static wait_queue_head_t pcf_wait;
#endif
#if (LINUX_VERSION_CODE >= 0x020301)
init_waitqueue_head(&pcf_wait);
#endif
except for this, semantics remain the same (but using a plain
wait_queue_head_t instead of a pointer to a wait_queue)
* I had to change the semantics of sensors_register_entry slightly,
to make the monitoring of /proc/sys/dev/* files possible for kernels
2.3.27 and newer. It now takes an additional parameter, which you
can specify as THIS_MODULE.
* THIS_MODULE is only defined in kernels 2.3.13 and later; added
it to compat.h and the compatibility section of mkpatch.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@640 7894878c-1315-0410-8ee3-d5d059ff63e0
Added/changed:
- Update, if necessary, the version number of `sensors'
(edit prog/sensors/sensors.c and change the VERSION define)
- Update if necessary, the version number of libsensors
(edit lib/Module.mk and change LIBMAINVER and/or LIBMINORVER)
Remember: update main number when interface changes, minor if new
functionality is added, and patch if only bugs are fixed.
- Update lm_sensors.lsm and send it to the LSM by mailing it to
lsm@execpc.com with the subject `add' (no quotes).
Also bumped up the `sensors' version number (should have done that
long ago), it is now at 1.0.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@636 7894878c-1315-0410-8ee3-d5d059ff63e0
/etc/ld.so.conf if you get libsensors not found problems.
Had this one two or three times in the ticket area the last weeks...
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@633 7894878c-1315-0410-8ee3-d5d059ff63e0
Short and simple. Give it a try. If you didn't know which sensor
was your CPU sensor this will definitely tell you.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@621 7894878c-1315-0410-8ee3-d5d059ff63e0
(1.75 to 1.30 Volts) as specified in Intel document
243773302.pdf. Lower voltages are coming!
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@617 7894878c-1315-0410-8ee3-d5d059ff63e0
Mark D. Studebaker