linux-toradex.git/drivers/hwmon, branch v2.6.23.5

hwmon: End of I/O region off-by-one

2007-09-09T14:38:37+00:00

Fix an off-by-one error in the I/O region declaration of two
hardware monitoring drivers (lm78 and w83781d.) We were requesting
one extra port at the end of the region.

Signed-off-by: Jean Delvare 
Signed-off-by: Mark M. Hoffman

hwmon: (smsc47m1) restore missing name attribute

2007-08-12T18:39:44+00:00

The smsc47m1 driver no longer creates the name attribute used by
libsensors to identify chip types. It was lost during the conversion
to a platform driver. I was fooled by the fact that we do have a
group with all attributes, but only to delete them all at once. The
group is not used to create the attributes, so we have to explicitly
create the name attribute.

This fixes lm-sensors ticket #2236:
http://lm-sensors.org/ticket/2236

Signed-off-by: Jean Delvare 
Signed-off-by: Mark M. Hoffman

hwmon: (w83627ehf) don't assume bank 0

2007-08-12T18:38:31+00:00

Don't assume that the default bank is 0. For one thing, we don't even
set it to 0 when the driver is loaded, so the initial state might be
different. For another, something (say, the BIOS) might access the chip
and leave with the bank set to something different, so assuming that
the bank value is 0 is not safe.

Signed-off-by: Jean Delvare 
Signed-off-by: Mark M. Hoffman

hwmon: (w83627ehf) read fan_div values during probe

2007-08-12T18:37:19+00:00

This patch forces the driver to read the fan divider values during early init.
Otherwise, a call to store_fan_min() could access uninitialized variables.

Signed-off-by: Mark M. Hoffman 
Signed-off-by: Jean Delvare

hwmon: fix w83781d temp sensor type setting

2007-08-11T18:22:57+00:00

Commit 348753379a7704087603dad403603e825422fd9a introduced a regression that
caused temp2 and temp3 sensor type settings to be written to temp1 instead.
The result is that temp sensor readings could be way off.

Signed-off-by: Mark M. Hoffman

hwmon: fscher read control bugfix

2007-07-31T01:14:00+00:00

Here is a small fscher bugfix for 2.6.23 merging, lifted from my other fscher
work, as requested by Jean. The current driver has a control sysfs attribute,
which shows the contents of the control register, but the underlying
global_control value in the data structure currently never gets filled with
the actual contents of this register.

Signed-off-by: Hans de Goede 
Acked-by: Jean Delvare 
Signed-off-by: Mark M. Hoffman

hwmon: make abituguru3_read_increment_offset() static

2007-07-31T01:11:21+00:00

abituguru3_read_increment_offset() can become static.

Signed-off-by: Adrian Bunk 
Acked-by: Hans de Goede 
Signed-off-by: Mark M. Hoffman

hwmon: Fix regression caused by typo in lm90.c

2007-07-31T01:10:34+00:00

The commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=32c82a934759b2c9939c9e25865c2d7d1204b9e8
broke lm90 for my (Asus V6VA) laptop.

Before 2.6.23-rc1 and with the following patch, I get:

[g ~]$ sensors
max6657-i2c-0-4c
Adapter: SMBus I801 adapter at 0400
M/B Temp:    +64Â°C  (low  =    +0Â°C, high =  +127Â°C)
CPU Temp:  +78.9Â°C  (low  = +73.2Â°C, high = +88.2Â°C)
M/B Crit:   +105Â°C  (hyst =   +95Â°C)
CPU Crit:   +105Â°C  (hyst =   +95Â°C)

Which regressed into:

[g ~]$ sensors
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
zsh: 2701 exit 1     sensors

and dmesg contains:

i2c-adapter i2c-0: Unsupported chip (man_id=0x4D, chip_id=0x4D).

It seems to be a typo, as address 0X4F is mentionned nowhere else in the file,
and my chip is actually at 0x4C.

Signed-off-by: Guillaume Chazarain 
Signed-off-by: Jean Delvare 
Signed-off-by: Mark M. Hoffman

hwmon: (applesmc) add temperature sensors set for Macbook

2007-07-31T01:09:49+00:00

Signed-off-by: Nicolas Boichat 
Acked-by: Jean Delvare 
Cc: Martin Szulecki 
Cc: Dmitry Torokhov 
Signed-off-by: Andrew Morton 
Signed-off-by: Mark M. Hoffman

hwmon: fscher control update bugfix

2007-07-31T01:08:38+00:00

Here is another small fscher bugfix for 2.6.23 merging, this was caught by Jean
while reviewing my other bugfix. The driver was updating its copy of the
control register as if it was clear to write, but its regular read/write.  This
patch fixes this.

Signed-off-by: Hans de Goede 
Acked-by: Jean Delvare 
Signed-off-by: Mark M. Hoffman