linux.git/drivers/hwmon, branch v2.6.35-rc4 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git hwmon: (k8temp) Bypass core swapping on single-core processors 2010-06-20T07:22:32+00:00 Jean Delvare khali@linux-fr.org 2010-06-20T07:22:32+00:00 cd4de21f7e65a8cd04860f5661b3c18648ee52a1 Commit a2e066bba2aad6583e3ff648bf28339d6c9f0898 introduced core swapping for CPU models 64 and later. I recently had a report about a Sempron 3200+, model 95, for which this patch broke temperature reading. It happens that this is a single-core processor, so the effect of the swapping was to read a temperature value for a core that didn't exist, leading to an incorrect value (-49 degrees C.) Disabling core swapping on singe-core processors should fix this. Additional comment from Andreas: The BKDG says Thermal Sensor Core Select (ThermSenseCoreSel)-Bit 2. This bit selects the CPU whose temperature is reported in the CurTemp field. This bit only applies to dual core processors. For single core processors CPU0 Thermal Sensor is always selected. k8temp_probe() correctly detected that SEL_CORE can't be used on single core CPU. Thus k8temp did never update the temperature values stored in temp[1][x] and -49 degrees was reported. For single core CPUs we must use the values read into temp[0][x]. Signed-off-by: Jean Delvare <khali@linux-fr.org> Tested-by: Rick Moritz <rhavin@gmx.net> Acked-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: stable@kernel.org 
Commit a2e066bba2aad6583e3ff648bf28339d6c9f0898 introduced core
swapping for CPU models 64 and later. I recently had a report about
a Sempron 3200+, model 95, for which this patch broke temperature
reading. It happens that this is a single-core processor, so the
effect of the swapping was to read a temperature value for a core
that didn't exist, leading to an incorrect value (-49 degrees C.)

Disabling core swapping on singe-core processors should fix this.

Additional comment from Andreas:

The BKDG says

  Thermal Sensor Core Select (ThermSenseCoreSel)-Bit 2. This bit
  selects the CPU whose temperature is reported in the CurTemp
  field. This bit only applies to dual core processors. For
  single core processors CPU0 Thermal Sensor is always selected.

k8temp_probe() correctly detected that SEL_CORE can't be used on single
core CPU. Thus k8temp did never update the temperature values stored
in temp[1][x] and -49 degrees was reported. For single core CPUs we
must use the values read into temp[0][x].

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Rick Moritz <rhavin@gmx.net>
Acked-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: stable@kernel.org
hwmon: (i5k_amb) Fix sysfs attribute for lockdep 2010-06-20T07:22:31+00:00 KAMEZAWA Hiroyuki kamezawa.hiroyu@jp.fujitsu.com 2010-06-20T07:22:31+00:00 0e6c7870856c7fb4ee054d28ac253b2d3d0c7e36 i5k_amb.ko uses dynamically allocated memory (by kmalloc) for attributes passed to sysfs. So, sysfs_attr_init() should be called for working happy with lockdep. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: stable@kernel.org [2.6.34 only] 
i5k_amb.ko uses dynamically allocated memory (by kmalloc) for
attributes passed to sysfs. So, sysfs_attr_init() should be called
for working happy with lockdep.

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org [2.6.34 only]
hwmon: (k10temp) Do not blacklist known working CPU models 2010-06-20T07:22:31+00:00 Jean Delvare khali@linux-fr.org 2010-06-20T07:22:31+00:00 eefc2d9e3d4f8820f2c128a0e44a23de28b1ed64 When detecting AM2+ or AM3 socket with DDR2, only blacklist cores which are known to exist in AM2+ format. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Clemens Ladisch <clemens@ladisch.de> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: stable@kernel.org 
When detecting AM2+ or AM3 socket with DDR2, only blacklist cores
which are known to exist in AM2+ format.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: stable@kernel.org
i2c: Remove all i2c_set_clientdata(client, NULL) in drivers 2010-06-03T09:33:58+00:00 Wolfram Sang w.sang@pengutronix.de 2010-06-03T09:33:58+00:00 fbae3fb1546e199ab0cd185348f8124411a1ca9d I2C drivers can use the clientdata-pointer to point to private data. As I2C devices are not really unregistered, but merely detached from their driver, it used to be the drivers obligation to clear this pointer during remove() or a failed probe(). As a couple of drivers forgot to do this, it was agreed that it was cleaner if the i2c-core does this clearance when appropriate, as there is no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. This feature was added to the core with commit e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: Richard Purdie <rpurdie@linux.intel.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Jean Delvare <khali@linux-fr.org> 
I2C drivers can use the clientdata-pointer to point to private data. As I2C
devices are not really unregistered, but merely detached from their driver, it
used to be the drivers obligation to clear this pointer during remove() or a
failed probe(). As a couple of drivers forgot to do this, it was agreed that it
was cleaner if the i2c-core does this clearance when appropriate, as there is
no guarantee for the lifetime of the clientdata-pointer after remove() anyhow.
This feature was added to the core with commit
e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers.

As there is no need anymore to clear the clientdata-pointer, remove all current
occurrences in the drivers to simplify the code and prevent confusion.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Richard Purdie <rpurdie@linux.intel.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
hwmon: (lm75) Add support for the Texas Instruments TMP105 2010-05-27T17:59:03+00:00 Shubhrajyoti Datta shubhrajyoti@ti.com 2010-05-27T17:59:03+00:00 6d034059eef080a0cdda92b45baa18cb00a19835 Add support for the Texas Instruments TMP105 temperature sensor device. Signed-off-by: Shubhrajyoti Datta <shubhrajyoti@ti.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Jean Delvare <khali@linux-fr.org> 
Add support for the Texas Instruments TMP105 temperature sensor
device.

Signed-off-by: Shubhrajyoti Datta <shubhrajyoti@ti.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
hwmon: (ltc4245) Read only one GPIO pin 2010-05-27T17:59:02+00:00 Ira W. Snyder iws@ovro.caltech.edu 2010-05-27T17:59:02+00:00 df16dd53c575d0cb9dbee20a3149927c862a9ff6 Read only one of the GPIO pins as an analog voltage. The ADC can be switched to a different GPIO pin at runtime, but this is not supported. Previously, this driver would report the analog voltage of the currently selected GPIO pin as all three GPIO voltages: in9_input, in10_input and in11_input. Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu> Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: stable@kernel.org 
Read only one of the GPIO pins as an analog voltage. The ADC can be
switched to a different GPIO pin at runtime, but this is not supported.

Previously, this driver would report the analog voltage of the currently
selected GPIO pin as all three GPIO voltages: in9_input, in10_input and
in11_input.

Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
hwmon: (dme1737) Add SCH5127 support 2010-05-27T17:59:01+00:00 Juerg Haefliger juergh@gmail.com 2010-05-27T17:59:01+00:00 ea694431f9c862bd409c90ba1cb3bdc6fdde8635 Add support for the hardware monitoring capabilities of the SCH5127 chip to the dme1737 driver. Signed-off-by: Juerg Haefliger <juergh@gmail.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Tested-by: Jeff Rickman <jrickman@myamigos.us> 
Add support for the hardware monitoring capabilities of the SCH5127
chip to the dme1737 driver.

Signed-off-by: Juerg Haefliger <juergh@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Jeff Rickman <jrickman@myamigos.us>
hwmon: (tmp102) Don't always stop chip at exit 2010-05-27T17:58:59+00:00 Jean Delvare khali@linux-fr.org 2010-05-27T17:58:59+00:00 38806bda6b7c8473c47a967a514260c1a1c32c2e Only stop the chip at driver exit if it was stopped when driver was loaded. Leave it running otherwise. Also restore the device configuration if probe failed, to not leave the system in a dangling state. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Steven King <sfking@fdwdc.com> 
Only stop the chip at driver exit if it was stopped when driver was
loaded. Leave it running otherwise.

Also restore the device configuration if probe failed, to not leave
the system in a dangling state.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Steven King <sfking@fdwdc.com>
hwmon: (tmp102) Fix suspend and resume functions 2010-05-27T17:58:58+00:00 Jean Delvare khali@linux-fr.org 2010-05-27T17:58:58+00:00 8d4dee98b10050db9c32a449e460a2f69bb558ec Suspend and resume functions shouldn't overwrite the configuration register. They should only alter the one bit they have to touch. Also don't assume that register reads and writes always succeed. Handle errors properly, shall they happen. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Steven King <sfking@fdwdc.com> 
Suspend and resume functions shouldn't overwrite the configuration
register. They should only alter the one bit they have to touch.

Also don't assume that register reads and writes always succeed.
Handle errors properly, shall they happen.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Steven King <sfking@fdwdc.com>
hwmon: (tmp102) Various fixes 2010-05-27T17:58:57+00:00 Jean Delvare khali@linux-fr.org 2010-05-27T17:58:57+00:00 cff37c9e82e022068840b3d33167e64c6a0ecc06 Fixes from my driver review: http://lists.lm-sensors.org/pipermail/lm-sensors/2010-March/028051.html Only the small changes are in there, more important changes will come later separately as time permits. * Drop the remnants of the now gone detect function * The TMP102 has no known compatible chip * Include the right header files * Clarify why byte swapping of register values is needed * Strip resolution info bit from temperature register value * Set cache lifetime to 1/3 second * Don't arbitrarily reject limit values; clamp as needed * Make limit writing unconditional * Don't check for transaction types the driver doesn't use * Properly check for error when setting configuration * Report error on failed probe * Make the driver load automatically where needed * Various other minor fixes Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Steven King <sfking@fdwdc.com> 
Fixes from my driver review:
http://lists.lm-sensors.org/pipermail/lm-sensors/2010-March/028051.html

Only the small changes are in there, more important changes will come
later separately as time permits.

* Drop the remnants of the now gone detect function
* The TMP102 has no known compatible chip
* Include the right header files
* Clarify why byte swapping of register values is needed
* Strip resolution info bit from temperature register value
* Set cache lifetime to 1/3 second
* Don't arbitrarily reject limit values; clamp as needed
* Make limit writing unconditional
* Don't check for transaction types the driver doesn't use
* Properly check for error when setting configuration
* Report error on failed probe
* Make the driver load automatically where needed
* Various other minor fixes

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Steven King <sfking@fdwdc.com>