class device directory rather than directly in the device directory.
The latter is what all drivers do at the moment, but in the long run
the former is preferred as it prevents attribute name collisions.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5093 7894878c-1315-0410-8ee3-d5d059ff63e0
guessing it from how the device identifier looks like. For kernels
<= 2.6.17, we use the bus symlink instead. For kernels <= 2.6.11,
neither symlink exist so we fallback to the old type guessing
approach. It doesn't really matter as all hwmon devices were
i2c devices back then.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5092 7894878c-1315-0410-8ee3-d5d059ff63e0
Gary Funck:
* If we create /etc/sysconfig/lm_sensors, there's no point in printing
the modprobe commands on the screen.
* Otherwise, suggest /etc/rc.d/rc.local as the init script where to put
the commands.
* If /etc/modprobe.d exists, create a file there to store the module
options, rather than printing them on the screen.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5080 7894878c-1315-0410-8ee3-d5d059ff63e0
measured voltage value are now named inX_input, not just inX, but the
default configuration file was not properly updated to reflect this. This
caused errors to be displayed by "sensors" for the g520sm, lm80 and pc87366
chips. Reported by Aurelien Jarno.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5076 7894878c-1315-0410-8ee3-d5d059ff63e0
Instead, access sysfs directly, using 3 embedded helper
functions. My motivations for doing this are:
* As far as I know, libsysfs is no longer maintained.
* libsysfs does much more than we need. For example, when asking for a
device attribute list, libsysfs will read the contents and permissions
of all attributes. Not only does this waste CPU cycles per se, but in
the case of hwmon driver it also triggers register reads, which can be
slow for SMBus chips.
* libsysfs enforces the difference between devices and class devices,
while future changes will be easier if we can handle both types alike.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5067 7894878c-1315-0410-8ee3-d5d059ff63e0
* The drivers are no longer in this package.
* Drop all references to i2c, these aren't related to sensors per se and
belong elsewhere.
* Random updates, fix broken references, clarify some parts.
* Add references to the relevant manual pages.
* Drop references to freshmeat, they don't really help.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5056 7894878c-1315-0410-8ee3-d5d059ff63e0
multiplexer, it should be handled transparently at the kernel level.
On top of that, it can't be detected reliably, and the pca9540 driver
doesn't even exist in Linux 2.6.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5045 7894878c-1315-0410-8ee3-d5d059ff63e0
W83782D chips. We've never seen any hardware monitoring chip at these
addresses. The correponding kernel drivers will be modified to no
longer probe these addresses either.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5016 7894878c-1315-0410-8ee3-d5d059ff63e0
but this is a variant of the LPC47B357, and that one has no hardware
monitoring features, so for now we assume that the LPC47B367 has no
hardware monitoring features either.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5009 7894878c-1315-0410-8ee3-d5d059ff63e0
be found, fallback to /etc/sensors.conf. This allows for an old
libsensors and a new libsensors to be installed in parallel, and each
one has its own configuration file.
One important change here is that the default configuration file will
be installed as /etc/sensors3.conf by "make install".
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4990 7894878c-1315-0410-8ee3-d5d059ff63e0
