Changes in sensors.c:
sensors_detect now skips addresses which are already taken. Even a
force parameter can not override this, as it could lead to major
problems.
For ISA addresses, the same is done; but the client drivers still need
a check if they claim more than one ISA address (as all of the current
ISA clients do).
Changes in chip drivers:
Removed the comment about needing address registration
Changes in i2cdetect.c:
Marks addresses which are already claimed
Changes in sensors-detect:
Warns when an address is already claimed, and skips it.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@667 7894878c-1315-0410-8ee3-d5d059ff63e0
Could somebody with a LM78 or W83781D on both SMBus and ISA bus please test
this? It should say `Alias of the chip on I2C bus `...' address `...''
when scanning the ISA bus.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@664 7894878c-1315-0410-8ee3-d5d059ff63e0
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
Frodo Looijaard