It now warns you about built-in drivers, and should always work. It will
still give a too long list of modules if some things are built into the
kernel. There is no real solution to this; the best thing to do would
probably be to ask the user where the kernel tree is located, and use
.config to determine what is built into the kernel. But not everybody
has such a kernel tree - especially once we get to the point where
people will distribute binary versions.
I also updated the list of undetectable adapter.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@589 7894878c-1315-0410-8ee3-d5d059ff63e0
* Removed several superfluous (struct i2c_client *) casts (they were left
from the time we had separate structs for smbus and isa)
* Removed the internal lists of registered clients
They have not been used for quite some time now, took memory space,
and limited the maximum number of clients that could be registered.
Also removed two small Makefile errors - I am happy I caught them before
the next release!
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@582 7894878c-1315-0410-8ee3-d5d059ff63e0
The Makefile now examine $(LINUX)/.config to see what modules need to be
compiled. It compiles only those modules which were either not configured
in at all, or were built as modules (ie. drivers which are built-in in the
kernel are not built, as they can not be overruled).
The above is still potentially dangerous, if we break the interface of
our modules. Still, it is much better than it was.
C
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@575 7894878c-1315-0410-8ee3-d5d059ff63e0
It now dies with an error message if it fails to generate the correct diffs,
instead of continuing silently.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@574 7894878c-1315-0410-8ee3-d5d059ff63e0
be working perfectly. Of course, some real-world users might find something
I didn't... BTW- I caught a minor bug which I thought was funny, and checked
lm75.c to see if it was there from the start... and it was! So, I managed to
catch a bug in lm75.c which might have resulted in bad temp_hyst readings
during that short period between setting new limits and the next valid update.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@564 7894878c-1315-0410-8ee3-d5d059ff63e0
Most important change: GL518SM-rev00 can't use kernel threads on 2.0 and
early 2.1 kernels
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@563 7894878c-1315-0410-8ee3-d5d059ff63e0
Patching kernel 2.2.12 and configuring it works now without any problem;
I am right now building it.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@555 7894878c-1315-0410-8ee3-d5d059ff63e0
again.
No testing yet, just a normal compile without kernel patching. Expect more
of these minor patches today,
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@553 7894878c-1315-0410-8ee3-d5d059ff63e0
package, even after the kernel was also patched for lm_sensors.
This means generating diffs now works always.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@552 7894878c-1315-0410-8ee3-d5d059ff63e0
* mkpatch now correctly works when kernel-side files do not yet exist.
I forgot to propagate a change in the i2c version.
* __init* handling in mkpatch and compat.h
* New i801 defines added to mkpatch
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@545 7894878c-1315-0410-8ee3-d5d059ff63e0
Changed adm9240 confidence from 8 to 7 to let adm1022 win,
not sure about register 0x3F in adm1022.
Removed 0x69 from i2c range on all drivers, that address
looks entrenched for clock chips.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@540 7894878c-1315-0410-8ee3-d5d059ff63e0