summaryrefslogtreecommitdiffstats
path: root/drivers/hwmon/f71805f.c
Commit message (Collapse)AuthorAgeFilesLines
* hwmon: Include <linux/io.h> instead of <asm/io.h>H Hartley Sweeten2009-09-151-1/+1
| | | | | | | | | | | | | | 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 conflictsJean Delvare2009-01-071-0/+5
| | | | | | | | | | | | | | | | | | 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 IDJean Delvare2008-02-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | 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 deviceTony Jones2007-10-091-5/+5
| | | | | | | | | 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 supportedJean Delvare2007-10-091-1/+4
| | | | | | | | | | | 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 modePhil Endecott2007-07-191-1/+166
| | | | | | | | | | 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 unloadJean Delvare2007-07-191-1/+1
| | | | | | | | | | | | | | | 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()Jean Delvare2007-07-191-6/+3
| | | | | | | | 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>
* hwmon: Request the I/O regions in platform driversJean Delvare2007-05-081-1/+15
| | | | | | | | | | | | | | | | | | 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>
* hwmon/f71805f: Fix a race conditionJean Delvare2007-02-141-7/+1
| | | | | | | | | | | | I think I introduced a potential race condition bug with commit 51c997d80e1f625aea3426a8a9087f5830ac6db3. 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>
* hwmon: Simplify the locking model of two driversJean Delvare2007-02-141-16/+6
| | | | | | | | | | | | | | | | 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>
* hwmon/f71805f: Fix the device address decodingJean Delvare2006-12-121-3/+4
| | | | | | | 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>
* hwmon/f71805f: Always create all fan inputsJean Delvare2006-12-121-51/+23
| | | | | | | 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>
* hwmon/f71805f: Add support for the Fintek F71872F/FG chipJean Delvare2006-12-121-43/+187
| | | | | | | | | | | | | | | | | 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>
* hwmon/f71805f: Add support for "speed mode" fan speed controlJean Delvare2006-12-121-1/+49
| | | | | | | | 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>
* hwmon/f71805f: Support DC fan speed control modeJean Delvare2006-12-121-3/+43
| | | | | | In DC mode, the pwmN_freq files are not created. Signed-off-by: Jean Delvare <khali@linux-fr.org>
* hwmon/f71805f: Let the user adjust the PWM base frequencyJean Delvare2006-12-121-1/+62
| | | | | | | Different frequencies can give better results depending on the exact fan model used. Signed-off-by: Jean Delvare <khali@linux-fr.org>
* hwmon/f71805f: Add manual fan speed controlJean Delvare2006-12-121-1/+144
| | | | | | | | 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>
* hwmon/f71805f: Store the fan control registersJean Delvare2006-12-121-11/+15
| | | | | | | | 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>
* hwmon: Fix unchecked return status, batch 4Jean Delvare2006-09-281-121/+203
| | | | | | | | | | | | | | | | | 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>
* hwmon: Add individual alarm files to 4 driversJean Delvare2006-09-281-11/+35
| | | | | | | | | | | | | 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>
* [PATCH] f71805f: Resource needs not be globalJean Delvare2006-06-221-8/+7
| | | | | | | | 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>
* [PATCH] hwmon: f71805f semaphore to mutex conversionsJean Delvare2006-03-231-28/+29
| | | | | | | | 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>
* [PATCH] hwmon: Use attribute arrays in f71805fJean Delvare2006-03-231-115/+103
| | | | | | | | | | | | | 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>
* [PATCH] hwmon: New f71805f driverJean Delvare2006-02-061-0/+908
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>
OpenPOWER on IntegriCloud