I2C algorithms no longer have names in Linux 2.6, and anyway they are
implementation details user-space doesn't care about. No third party
application is known to have ever used this particular feature of
libsensors. "sensord" and "sensors" no longer do.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4208 7894878c-1315-0410-8ee3-d5d059ff63e0
The algorithm names are no more available since Linux 2.6, and were not
very useful anyway.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4206 7894878c-1315-0410-8ee3-d5d059ff63e0
We don't need to strdup() the file names, we can use them directly.
As a side effect, this fixes a memory leak which was happening if
option -c was specified more than once on the command line.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4205 7894878c-1315-0410-8ee3-d5d059ff63e0
sensord: Add pc87247 support (fans only).
sensors: Add pc87247 support (fans only).
sensors-detect: Advertise the upcoming pc87427 driver.
Thanks to Amir Habibi at Candelis for setting up a test system.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4196 7894878c-1315-0410-8ee3-d5d059ff63e0
input order to match the Linux 2.6 driver.
libsensors: Change vt1211 temp3-7 magnitude from 1 to 3.
sensors.conf.eg: Adjust the vt1211 section to match the new driver
interface.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4168 7894878c-1315-0410-8ee3-d5d059ff63e0
driver. Some are handled by the tveeprom driver, which doesn't create
the eeprom interface file. So we must really test for the eeprom file,
and not the device directory.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4167 7894878c-1315-0410-8ee3-d5d059ff63e0
driver. Some are handled by the tveeprom driver, which doesn't create
the eeprom interface file. So we must really test for the eeprom file,
and not the device directory.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4165 7894878c-1315-0410-8ee3-d5d059ff63e0
to confuse users a lot, to report the lack of hwmon driver as an error.
prog/sensors: Clearer error messages when no sensors are found. The
most frequent cause is a lack of drivers, not procfs/sysfs problems.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4159 7894878c-1315-0410-8ee3-d5d059ff63e0
We are already using mktemp elsewhere in the script, and it seems to be
more widely available than tempfile.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4153 7894878c-1315-0410-8ee3-d5d059ff63e0
For families where it makes sense (ITE, Winbond, Fintek), when we have
an unknown Super-I/O, we scan all logical devices in search of one
with the typical address for hardware monitoring (0x290). If we find
it, we let the user know there are probably sensors in the chip.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4144 7894878c-1315-0410-8ee3-d5d059ff63e0
The detection is based of the PCI device class (SMBus is 0x0c05).
This will let us spot new adapters. Of course we can't load or even
suggest a driver for an unknown adapter, but at least the user will
know there's something to be investigated, and this should help us
when users report such configurations.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4143 7894878c-1315-0410-8ee3-d5d059ff63e0
(Linux 2.6). Still fallback to /proc (Linux 2.4). sysfs provides the PCI
device domain and class, which were hard to get from /proc.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4142 7894878c-1315-0410-8ee3-d5d059ff63e0
with the Super-I/O detection, and less reliable. Our w83627ehf driver
only supports the Super-I/O detection anyway.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4141 7894878c-1315-0410-8ee3-d5d059ff63e0
There are too many of these, the list was not up-to-date. And there
are different drivers which can give access to their I2C busses,
we can't guess which one the user wants. It was somewhat confusing
to suggest a driver which is not in mainline anyway.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4140 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare