| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
In DC mode, the pwmN_freq files are not created.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
| |
|
|
|
|
|
| |
Different frequencies can give better results depending on the exact fan
model used.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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 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 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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
