kernel/git/stable/linux.git/drivers/hwmon, branch linux-2.6.27.y

hwmon/f71882fg: Set platform drvdata to NULL later

2011-04-30T14:53:14+00:00

commit d9ebaa45472c92704f4814682eec21455edcfa1f upstream. This avoids a possible race leading to trying to dereference NULL. Signed-off-by: Hans de Goede Acked-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

hwmon: (via686a) Initialize fan_div values

2011-04-30T14:52:54+00:00

commit f790674d3f87df6390828ac21a7d1530f71b59c8 upstream. Functions set_fan_min() and set_fan_div() assume that the fan_div values have already been read from the register. The driver currently doesn't initialize them at load time, they are only set when function via686a_update_device() is called. This means that set_fan_min() and set_fan_div() misbehave if, for example, "sensors -s" is called before any monitoring application (e.g. "sensors") is has been run. Fix the problem by always initializing the fan_div values at device bind time. Signed-off-by: Jean Delvare Acked-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

hwmon: (adm1026) Fix setting fan_div

2011-02-09T21:15:36+00:00

commit 52bc9802ce849d0d287cc5fe76d06b0daa3986ca upstream. Prevent setting fan_div from stomping on other fans that share the same I2C register. Signed-off-by: Gabriele Gorla Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

hwmon: (adm1026) Allow 1 as a valid divider value

2011-02-09T21:15:36+00:00

commit 8b0f1840a46449e1946fc88860ef3ec8d6b1c2c7 upstream. Allow 1 as a valid div value as specified in the ADM1026 datasheet. Signed-off-by: Gabriele Gorla Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

hwmon: (f75375s) Do not overwrite values read from registers

2010-09-20T20:03:22+00:00

commit c3b327d60bbba3f5ff8fd87d1efc0e95eb6c121b upstream. All bits in the values read from registers to be used for the next write were getting overwritten, avoid doing so to not mess with the current configuration. Signed-off-by: Guillem Jover Cc: Riku Voipio Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

hwmon: (f75375s) Shift control mode to the correct bit position

2010-09-20T20:03:21+00:00

commit 96f3640894012be7dd15a384566bfdc18297bc6c upstream. The spec notes that fan0 and fan1 control mode bits are located in bits 7-6 and 5-4 respectively, but the FAN_CTRL_MODE macro was making the bits shift by 5 instead of by 4. Signed-off-by: Guillem Jover Cc: Riku Voipio Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

hwmon: (coretemp) Skip duplicate CPU entries

2010-08-02T17:18:49+00:00

commit d883b9f0977269d519469da72faec6a7f72cb489 upstream. On hyper-threaded CPUs, each core appears twice in the CPU list. Skip the second entry to avoid duplicate sensors. Signed-off-by: Jean Delvare Acked-by: Huaxu Wan Signed-off-by: Greg Kroah-Hartman

hwmon: (coretemp) Properly label the sensors

2010-08-02T17:18:49+00:00

commit 3f4f09b4be35d38d6e2bf22c989443e65e70fc4c upstream. Don't assume that CPU entry number and core ID always match. It worked in the simple cases (single CPU, no HT) but fails on multi-CPU systems. Signed-off-by: Jean Delvare Acked-by: Huaxu Wan Signed-off-by: Greg Kroah-Hartman

hwmon: (w83781d) Request I/O ports individually for probing

2010-05-26T21:27:08+00:00

commit b0bcdd3cd0adb85a7686b396ba50493871b1135c upstream. Different motherboards have different PNP declarations for W83781D/W83782D chips. Some declare the whole range of I/O ports (8 ports), some declare only the useful ports (2 ports at offset 5) and some declare fancy ranges, for example 4 ports at offset 4. To properly handle all cases, request all ports individually for probing. After we have determined that we really have a W83781D or W83782D chip, the useful port range will be requested again, as a single block. I did not see a board which needs this yet, but I know of one for lm78 driver and I'd like to keep the logic of these two drivers in sync. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

hwmon: (coretemp) Add missing newline to dev_warn() message

2010-04-01T22:52:29+00:00

commit 4d7a5644e4adfafe76c2bd8ee168e3f3b5dae3a8 upstream. Add missing newline to dev_warn() message string. This is more of an issue with older kernels that don't automatically add a newline if it was missing from the end of the previous line. Signed-off-by: Dean Nelson Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman