Detection threshold of 2/3 of the maximum speed is too low, some fans
will slow down to about that speed so controlled fans may be missed.
Use 3/4 as the threshold to avoid these false negatives.
Print the initial PWM values before letting the user change them. This
should be useful to better understand what happens next, and for user
support in general.
So we can not use the chip revision to detect the actual chip.
Merge entries for NCT5577D and NCT6776F into one.
List NCT5572D as another variant of W83677HG-I (NCT6775).
NCT6106D chip ID as observed on a real system is 0xC452, not 0x1061 as
claimed by the data sheet. Confirmed with Nuvoton that the correct
chip ID is 0xC452. Also list its variants NCT6102D and NCT6104D.
List NCT5532D as variant of NCT6779D. Data sheets list possible chip
IDs of 0xC561 and 0xC562, so detect and accept all chip revisions.
Point to new nct6775 driver for NCT6775, NCT6776, and NCT6779.
Patch from Jaromir Capik.
The device file /dev/port might be missing in some cases
and the sensors detection is terminated when the user
tries to detect sensors dependent on it's existence.
That's not correct -> it's not a reason for terminating
the detection.
/proc/modules so we will try to load it, even though it's already
available. It will succeed, however later attempts to remove the
driver will fail and such failures are reported at the end of the
script, which can be confusing.
So, use /sys/module instead of /proc/modules where available, as
built-in drivers are listed there too so we no longer attempt to load
already available drivers. As a consequence we also no longer attempt
to remove the drivers in question, thus clearing the error message.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6114 7894878c-1315-0410-8ee3-d5d059ff63e0
Take multiplexers into account when looking up the parent device of
each I2C adapter. We don't bother with old kernels as they didn't have
support for multiplexers anyway.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6085 7894878c-1315-0410-8ee3-d5d059ff63e0
Don't probe I2C buses on graphics cards by default. Their drivers will
typically instantiate the I2C slave devices themselves as needed, and
such probes have been occasionally reported to cause serious trouble.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6084 7894878c-1315-0410-8ee3-d5d059ff63e0
On recent systems, extra configuration files can live in
/etc/ld.so.conf.d, so check this directory too, before warning.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6045 7894878c-1315-0410-8ee3-d5d059ff63e0
attributes. These are defined in the standard sysfs interface for quite
some time, and at least three drivers (max6650, lm63 and applesmc)
implement them so we should support them.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6029 7894878c-1315-0410-8ee3-d5d059ff63e0
There is no rationale for having separate functions, both are static
and called only once. do_features() is calling helper functions to get
values it doesn't use and passes to get_features() directly. Having a
single function is more efficient and allows for per-action
optimizations.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6026 7894878c-1315-0410-8ee3-d5d059ff63e0
The leak in daemonize() is harmless, we're about to exit anyway. Fix
it still to make valgrind happy.
The leak in do_features() is real, as the function is called
periodically by the daemon, for all actions. If the intervals at set
low and the system has many sensors, the leak could be significant,
maybe 150 kB/day.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6025 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare