from the openSuse sensors package. This is a good idea because the
PWM/speed relation isn't linear, and it is frequent that the speed
changes are concentrated in the low PWM range.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4380 7894878c-1315-0410-8ee3-d5d059ff63e0
* Delete sample lm_sensors.sysconfig file, it is now generated by
sensors-detect.
* Fix several occurences of the configuration file name.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4378 7894878c-1315-0410-8ee3-d5d059ff63e0
* Update Makefile and README to mention hwmon class for newer
2.6 kernels
* Add missing shell declarations
* Update URI
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4373 7894878c-1315-0410-8ee3-d5d059ff63e0
* Drop outdated reference to /proc/sys/dev/sensors
* Bus type can be pci
* Make the examples more realistic
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4370 7894878c-1315-0410-8ee3-d5d059ff63e0
monitoring devices are better accessed through the hwmon class. Original
patch from Jeff Kosowsky.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4369 7894878c-1315-0410-8ee3-d5d059ff63e0
of in /usr/local/sbin. Many users have been complaining and several
distribtions were (rightly) modifying sensors-detect because of this.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4358 7894878c-1315-0410-8ee3-d5d059ff63e0
sequence to the longer one, and stop as soon as one enter sequence worked.
This avoids false positives.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4353 7894878c-1315-0410-8ee3-d5d059ff63e0
If we find that the register at offset 5 doesn't behave as it would for
an LM78 or W83781D chip, attempt to restore its 8 original bits rather
than just the 7 LSB.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4347 7894878c-1315-0410-8ee3-d5d059ff63e0
a RTC chip. We detect it only because it lives at address 0x50, which is
also used by some hardware monitoring chips and most notoriously EEPROMs.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4343 7894878c-1315-0410-8ee3-d5d059ff63e0
removal. In recent kernels we can detect i2c-isa devices by checking
the i2c bus number: i2c-isa always uses 9191 as its bus number.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4337 7894878c-1315-0410-8ee3-d5d059ff63e0
physical device. This change is required to survive the planned struct
class_dev removal from future 2.6 kernels.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4326 7894878c-1315-0410-8ee3-d5d059ff63e0
The i2c-ali1563 initialization looks quite broken to me:
* If the I/O space isn't enabled, we forcibly set 3 bits in
the PCI configuration space instead of just the one enabling
the I/O space.
* After that we pretend to check if the write worked, but we
don't actually read the new value from the register.
* It's probably not a good idea to enable the I/O space if no
base address has been set.
So I propose the following changes to that part of the driver:
* Merge ali1563_enable() into ali1563_setup().
* Check the base address before the I/O space enabled bit.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4324 7894878c-1315-0410-8ee3-d5d059ff63e0
* Add an explicit mask when writing the low byte of a word.
* Use I2C_SMBUS_BLOCK_MAX instead of hardcoding 32.
* Use boolean not instead of bitwise not for bit tests, it's clearer.
* Return proper error values rather than -1.
* Fix a race on device registration, initialization should be done
before the bus is registered.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4318 7894878c-1315-0410-8ee3-d5d059ff63e0
easier to find out which specific address causes problem if the system
freezes or the SMBus locks itself, for example.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4316 7894878c-1315-0410-8ee3-d5d059ff63e0
focus of the script, so their handling shouldn't take more time and
code than strictly necessary.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4313 7894878c-1315-0410-8ee3-d5d059ff63e0
was using a brute force approach, quite reliable but very slow. The new
code should be just as reliable but about ten times faster.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@4312 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare