Commit Graph

25 Commits

Author SHA1 Message Date
H Hartley Sweeten 6055fae8ac hwmon: Include <linux/io.h> instead of <asm/io.h>
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>
2009-09-15 17:18:13 +02:00
Jean Delvare b9acb64a38 hwmon: Check for ACPI resource conflicts
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>
2009-01-07 16:37:35 +01:00
Jean Delvare 67b671bceb hwmon: Let the user override the detected Super-I/O device ID
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>
2008-02-07 20:39:42 -05:00
Tony Jones 1beeffe433 hwmon: Convert from class_device to device
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>
2007-10-09 22:56:30 -04:00
Jean Delvare 9cab0217f3 hwmon: (f71805f) List the F71806F/FG as supported
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>
2007-10-09 22:56:28 -04:00
Phil Endecott aba5073d3f hwmon/f71805f: Add temperature-tracking fan control mode
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>
2007-07-19 14:22:15 -04:00
Jean Delvare 04a6217df2 hwmon: Fix a potential race condition on unload
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>
2007-07-19 14:22:14 -04:00
Jean Delvare 2df6d81157 hwmon: Use platform_device_add_data()
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>
2007-07-19 14:22:12 -04:00
Jean Delvare ce7ee4e80a hwmon: Request the I/O regions in platform drivers
My understanding of the resource management in the Linux 2.6 device
driver model is that the devices should declare their resources, and
then when a driver attaches to a device, it should request the
resources it will be using, so as to mark them busy. This is how the
PCI and PNP subsystems work, you can clearly see the two levels of
resources (declaration and request) in /proc/ioports for these
devices.

So I believe that our platform hardware monitoring drivers should
follow the same logic. At the moment, we only declare the resources
but we do not request them. This patch adds the I/O region request
and release calls.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Juerg Haefliger <juergh@gmail.com>
2007-05-08 17:21:59 +02:00
Jean Delvare a117dddf6b hwmon/f71805f: Fix a race condition
I think I introduced a potential race condition bug with commit
51c997d80e. I didn't realize it
back then, but platform_device_put and platform_device_release
both appear to free the platform data associated with the device.
This makes an explicit kfree redundant at best, and maybe even
racy, as it might occur while someone still holds a reference
to the platform device.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2007-02-14 21:15:05 +01:00
Jean Delvare 7f999aa726 hwmon: Simplify the locking model of two drivers
Many hardware monitoring drivers use two different mutexes, one to
protect their per-device data structure, and one to protect the
access to the device registers. These mutexes are essentially
redundant, as the drivers are transfering values between the device
registers and the data cache, so they almost always end up holding
both mutexes at the same time. Using a single mutex will make the
code more simple and faster.

I am changing only two of the affected drivers here, the authors
of the other affected drivers are welcome to submit similar patches
if they want.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2007-02-14 21:15:03 +01:00
Jean Delvare 75c990291d hwmon/f71805f: Fix the device address decoding
The lowest 3 bits are ignored, and the chip decodes all 8 addresses,
not only the 2 it needs.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-12 18:18:29 +01:00
Jean Delvare c7176cb515 hwmon/f71805f: Always create all fan inputs
Fans can be hotplugged, so we should create sysfs file even for fans
which are disabled at driver load time.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-12 18:18:29 +01:00
Jean Delvare 51c997d80e hwmon/f71805f: Add support for the Fintek F71872F/FG chip
Add support for the Fintek F71872F/FG Super-I/O chip. It is basically the
same as the Fintek F71805F/FG as far as hardware monitoring is concerned,
with two additional internal voltages monitored (VSB and battery), and 6
VID inputs (not yet supported.)

To make things a bit more confusing, two of the voltage input pins (in4
and in8) can be used for other functions. The driver reads the pin
configuration from the Super-I/O configuration space to decide whether
it must create interface files for these inputs or not.

Many thanks to Nikolay Derkach for testing the early iterations of this
code and reporting bugs.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-12 18:18:29 +01:00
Jean Delvare 315c7113b5 hwmon/f71805f: Add support for "speed mode" fan speed control
In "speed mode", the user specifies a target fan speed (in RPM) and the
chip automatically adjusts the PWM duty cycle (or DC output level) to
reach this target.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-12 18:18:27 +01:00
Jean Delvare e196783d54 hwmon/f71805f: Support DC fan speed control mode
In DC mode, the pwmN_freq files are not created.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-12 18:18:27 +01:00
Jean Delvare 6e2bc17b07 hwmon/f71805f: Let the user adjust the PWM base frequency
Different frequencies can give better results depending on the exact fan
model used.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-12 18:18:27 +01:00
Jean Delvare 95e353127d hwmon/f71805f: Add manual fan speed control
pwmN files are writable only in manual fan speed control mode.
In automatic fan speed control modes, they are read-only and
report the duty cycle chosen by the chip.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-12 18:18:26 +01:00
Jean Delvare 6b14a546a5 hwmon/f71805f: Store the fan control registers
So far we were only extracting the fan skip bit from the
fan control registers, but we'll soon need more bits so
better store the whole register values.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-12 18:18:26 +01:00
Jean Delvare 0e39e01c90 hwmon: Fix unchecked return status, batch 4
hwmon: Fix unchecked return status, batch 4

Fix up some hwmon drivers so that they no longer ignore return status
from device_create_file().

Note: f71805f actually checked the status from device_create_file
already. However it did not remove the files on device destruction.
It was also an opportunity to use sysfs_create/remove_group instead
of hand-made loops. This makes the changes much more important but
I think the result is worth it.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-28 15:31:18 -07:00
Jean Delvare 2d45771e6e hwmon: Add individual alarm files to 4 drivers
hwmon: Add individual alarm files to 4 drivers

Add individual sysfs files for all f71805f, lm63, lm83 and lm90 alarm
and fault conditions. This is a requirement for the planned
chip-independent libsensors. Almost all other hwmon drivers will need
the same improvement.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-28 15:31:15 -07:00
Jean Delvare 568825c8ed [PATCH] f71805f: Resource needs not be global
The F71805F I/O resource structure needs not be a global variable,
as the platform core allocs its own copy of it anyway.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-22 11:10:32 -07:00
Jean Delvare f08191849e [PATCH] hwmon: f71805f semaphore to mutex conversions
Convert the new f71805f hardware monitoring driver to use mutexes
instead of semaphores.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-23 14:21:52 -08:00
Jean Delvare 2488a39d23 [PATCH] hwmon: Use attribute arrays in f71805f
Convert the f71805f driver to use arrays of attributes. This shrinks the
compiled module from 12.0 kB to 9.6 kB. We certainly should do the same
for as many hardware monitoring drivers as possible.

This, together with a nice chip design by Fintek, makes this driver
very small, both in terms of number of lines of code and memory
consumption.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-23 14:21:49 -08:00
Jean Delvare e53004e20a [PATCH] hwmon: New f71805f driver
This is my f71805f hardware monitoring driver ported from lm_sensors
to Linux 2.6. This new driver differs from the other hardware monitoring
drivers in that it is implemented as a platform driver. This might not
be optimal yet (we would probably need a generic infrastructure and bus
type for Super-I/O logical devices) but it is certainly much better than
the i2c-isa solution.

Note that this driver requires lm_sensors CVS. I hope to get it
released as 2.10.0 soon.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-02-06 12:02:15 -08:00