linux-toradex.git/drivers/hwmon/f71805f.c, branch v3.2.30 Linux kernel for Apalis and Colibri modules hwmon: (f71805f) Fix clamping of temperature limits 2012-02-03T17:22:15+00:00 Jean Delvare khali@linux-fr.org 2012-01-20T15:09:23+00:00 543c6a0b0b461a32895b3edfada5ee57f8591905 commit 86b2bbfdbd1fcc4a3aa62ccd3f245c40c5ad5b85 upstream. Properly clamp temperature limits set by the user. Without this fix, attempts to write temperature limits above the maximum supported by the chip (255 degrees Celsius) would arbitrarily and unexpectedly result in the limit being set to 0 degree Celsius. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 86b2bbfdbd1fcc4a3aa62ccd3f245c40c5ad5b85 upstream.

Properly clamp temperature limits set by the user. Without this fix,
attempts to write temperature limits above the maximum supported by
the chip (255 degrees Celsius) would arbitrarily and unexpectedly
result in the limit being set to 0 degree Celsius.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hwmon: (f71805f) Use pr_fmt and pr_<level> 2011-01-08T18:55:07+00:00 Joe Perches joe@perches.com 2010-10-20T06:51:33+00:00 e54c5ad61f4e2c4fdfbdb8dff31fc604073d3550 Added #define pr_fmt KBUILD_MODNAME ": " fmt Converted printks to pr_<level> Coalesced any long formats Removed prefixes from formats Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> 
Added #define pr_fmt KBUILD_MODNAME ": " fmt
Converted printks to pr_<level>
Coalesced any long formats
Removed prefixes from formats

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
hwmon: Include <linux/io.h> instead of <asm/io.h> 2009-09-15T15:18:13+00:00 H Hartley Sweeten hartleys@visionengravers.com 2009-09-15T15:18:13+00:00 6055fae8aceee41471edfd1876e5617d16e028fe Drivers should be including <linux/io.h> instead of <asm/io.h>. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Alistair John Strachan <alistair@devzero.co.uk> Cc: Nicolas Boichat <nicolas@boichat.ch> Cc: Juerg Haefliger <juergh@gmail.com> Cc: Frank Seidel <frank@f-seidel.de> Acked-by: Jim Cromie <jim.cromie@gmail.com> Cc: "Mark M. Hoffman" <mhoffman@lightlink.com> Cc: Roger Lucas <vt8231@hiddenengine.co.uk> Signed-off-by: Jean Delvare <khali@linux-fr.org> 
Drivers should be including <linux/io.h> instead of <asm/io.h>.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Alistair John Strachan <alistair@devzero.co.uk>
Cc: Nicolas Boichat <nicolas@boichat.ch>
Cc: Juerg Haefliger <juergh@gmail.com>
Cc: Frank Seidel <frank@f-seidel.de>
Acked-by: Jim Cromie <jim.cromie@gmail.com>
Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>
Cc: Roger Lucas <vt8231@hiddenengine.co.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
hwmon: Check for ACPI resource conflicts 2009-01-07T15:37:35+00:00 Jean Delvare jdelvare@suse.de 2009-01-07T15:37:35+00:00 b9acb64a385c5b26fc392e0d58ac7b8e0a2cd812 Check for ACPI resource conflicts in hwmon drivers. I've included all Super-I/O and PCI drivers. I've voluntarily left out: * Vendor-specific drivers: if they conflicted on any system, this would pretty much mean that they conflict on all systems, and we would know by now. * Legacy ISA drivers (lm78 and w83781d): they only support chips found on old designs were ACPI either wasn't supported or didn't deal with thermal management. * Drivers accessing the I/O resources indirectly (e.g. through SMBus): the checks are already done where they belong, i.e. in the bus drivers. Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: David Hubbard <david.c.hubbard@gmail.com> 
Check for ACPI resource conflicts in hwmon drivers. I've included
all Super-I/O and PCI drivers.

I've voluntarily left out:
* Vendor-specific drivers: if they conflicted on any system, this would
  pretty much mean that they conflict on all systems, and we would know
  by now.
* Legacy ISA drivers (lm78 and w83781d): they only support chips found
  on old designs were ACPI either wasn't supported or didn't deal with
  thermal management.
* Drivers accessing the I/O resources indirectly (e.g. through SMBus):
  the checks are already done where they belong, i.e. in the bus drivers.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: David Hubbard <david.c.hubbard@gmail.com>
hwmon: Let the user override the detected Super-I/O device ID 2008-02-08T01:39:42+00:00 Jean Delvare khali@linux-fr.org 2007-12-06T22:13:42+00:00 67b671bceb4a8340a30929e9642620d99ed5ad76 While it is possible to force SMBus-based hardware monitoring chip drivers to drive a not officially supported device, we do not have this possibility for Super-I/O-based drivers. That's unfortunate because sometimes newer chips are fully compatible and just forcing the driver to load would work. Instead of that we have to tell the users to recompile the kernel driver, which isn't an easy task for everyone. So, I propose that we add a module parameter to all Super-I/O based hardware monitoring drivers, letting advanced users force the driver to load on their machine. The user has to provide the device ID of a supposedly compatible device. This requires looking at the source code or a datasheet, so I am confident that users can't randomly force a driver without knowing what they are doing. Thus this should be relatively safe. As you can see from the code, the implementation is pretty simple and unintrusive. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> 
While it is possible to force SMBus-based hardware monitoring chip
drivers to drive a not officially supported device, we do not have this
possibility for Super-I/O-based drivers. That's unfortunate because
sometimes newer chips are fully compatible and just forcing the driver
to load would work. Instead of that we have to tell the users to
recompile the kernel driver, which isn't an easy task for everyone.

So, I propose that we add a module parameter to all Super-I/O based
hardware monitoring drivers, letting advanced users force the driver
to load on their machine. The user has to provide the device ID of a
supposedly compatible device. This requires looking at the source code or
a datasheet, so I am confident that users can't randomly force a driver
without knowing what they are doing. Thus this should be relatively safe.

As you can see from the code, the implementation is pretty simple and
unintrusive.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
hwmon: Convert from class_device to device 2007-10-10T02:56:30+00:00 Tony Jones tonyj@suse.de 2007-08-20T20:46:20+00:00 1beeffe43311f64df8dd0ab08ff6b1858c58363f Convert from class_device to device for hwmon_device_register/unregister Signed-off-by: Tony Jones <tonyj@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> 
Convert from class_device to device for hwmon_device_register/unregister

Signed-off-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
hwmon: (f71805f) List the F71806F/FG as supported 2007-10-10T02:56:28+00:00 Jean Delvare khali@linux-fr.org 2007-07-15T08:36:06+00:00 9cab0217f3f35bd618363842576867badb72ca4b The Fintek F71806F/FG is compatible with the F71872F/FG, so it is already supported by the f71805f hardware monitoring driver. In fact, both chips have the same chip ID, so the driver can't even differentiate between them. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> 
The Fintek F71806F/FG is compatible with the F71872F/FG, so it is
already supported by the f71805f hardware monitoring driver. In fact,
both chips have the same chip ID, so the driver can't even
differentiate between them.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
hwmon/f71805f: Add temperature-tracking fan control mode 2007-07-19T18:22:15+00:00 Phil Endecott kernel@chezphil.org 2007-06-29T07:19:14+00:00 aba5073d3f4c928c89c483d85f8cff7cc9aa3312 Add support for the "temperature mode" fan speed control. In this mode, the user can define 3 temperature/speed trip points, and the chip will set the speed automatically according to the temperature changes. Signed-off-by: Phil Endecott <kernel@chezphil.org> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> 
Add support for the "temperature mode" fan speed control. In this mode,
the user can define 3 temperature/speed trip points, and the chip will
set the speed automatically according to the temperature changes.

Signed-off-by: Phil Endecott <kernel@chezphil.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
hwmon: Fix a potential race condition on unload 2007-07-19T18:22:14+00:00 Jean Delvare khali@linux-fr.org 2007-06-12T11:57:19+00:00 04a6217df28e3004ba4e76eb0a356a30f72c564f Fix a potential race condition when some hardware monitoring platform drivers are being unloaded. I believe that the driver data pointer shouldn't be cleared before all the sysfs files are removed, otherwise a sysfs callback might attempt to dereference a NULL pointer. I'm not sure exactly what the driver core protects drivers against, so let's play it safe. While we're here, clear the driver data pointer when probe fails, so as to not leave an invalid pointer behind us. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> 
Fix a potential race condition when some hardware monitoring platform
drivers are being unloaded. I believe that the driver data pointer
shouldn't be cleared before all the sysfs files are removed, otherwise
a sysfs callback might attempt to dereference a NULL pointer. I'm not
sure exactly what the driver core protects drivers against, so let's
play it safe.

While we're here, clear the driver data pointer when probe fails, so
as to not leave an invalid pointer behind us.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
hwmon: Use platform_device_add_data() 2007-07-19T18:22:12+00:00 Jean Delvare khali@linux-fr.org 2007-06-09T14:11:16+00:00 2df6d811574f46bea0d38bf91aa54df4c05488cd Use platform_device_add_data() in hardware monitoring drivers. This makes the code nicer and smaller too. Reported by David Hubbard. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: David Hubbard <david.c.hubbard@gmail.com> 
Use platform_device_add_data() in hardware monitoring drivers. This
makes the code nicer and smaller too. Reported by David Hubbard.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: David Hubbard <david.c.hubbard@gmail.com>