linux-toradex.git/drivers/hwmon/pc87360.c, branch tegra-9.12.13

hwmon: Check for ACPI resource conflicts

2009-01-07T15:37:35+00:00

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 
Acked-by: David Hubbard

hwmon/pc87360 separate alarm files: add therm-min/max/crit-alarms

2008-10-20T15:52:35+00:00

Adds therm-min/max/crit-alarm callbacks, sensor-device-attribute
declarations, and refs to those new decls in the macro used to initialize
the therm_group (of sysfs files)

The thermistors use voltage channels to measure; so they don't have a
fault-alarm, but unlike the other voltages, they do have an overtemp,
which we call crit (by convention).

[akpm@linux-foundation.org: cleanup]
Signed-off-by: Jim Cromie 
Cc: Jean Delvare 
Cc: "Mark M. Hoffman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hwmon/pc87360 separate alarm files: add dev_dbg help

2008-10-20T15:52:35+00:00

temp and vin status register values may be set by chip specifications, set
again by bios, or by this previously loaded driver.  Debug output nicely
displays modprobe init=\d actions.

Signed-off-by: Jim Cromie 
Cc: Jean Delvare 
Cc: "Mark M. Hoffman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hwmon/pc87360 separate alarm files: define LDNI_MAX const

2008-10-20T15:52:35+00:00

Driver handles 3 logical devices in fixed length array.  Give this a
define-d constant.

Signed-off-by: Jim Cromie 
Cc: Jean Delvare 
Cc: "Mark M. Hoffman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hwmon/pc87360 separate alarm files: add temp-min/max/crit/fault-alarms

2008-10-20T15:52:35+00:00

Adds temp-min/max/crit/fault-alarm callbacks, sensor-device-attribute
declarations, and refs to those new decls in the macro used to initialize
the temp_group (of sysfs files)

[akpm@linux-foundation.org: cleanups]
Signed-off-by: Jim Cromie 
Cc: Jean Delvare 
Cc: "Mark M. Hoffman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hwmon/pc87360 separate alarm files: add in-min/max-alarms

2008-10-20T15:52:35+00:00

Adds vin-min/max-alarm callbacks, sensor-device-attribute declarations,
and refs to those new decls in the macro used to initialize the vin_group
(of sysfs files)

[akpm@linux-foundation.org: cleanups]
Signed-off-by: Jim Cromie 
Cc: Jean Delvare 
Cc: "Mark M. Hoffman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hwmon/pc87360 separate alarm files: define some constants

2008-10-20T15:52:35+00:00

Bring hwmon/pc87360 into agreement with
Documentation/hwmon/sysfs-interface.

Patchset adds separate limit alarms for voltages and temps, it also adds
temp[123]_fault files.  On my Soekris, temps 1,2 are unused/unconnected,
so temp[123]_fault = 1,1,0 respectively.  This agrees with
/usr/bin/sensors, which has always shown them as OPEN.  Temps 4,5,6 are
thermistor based, and dont have a fault bit in their status register.

This patch:

2 different kinds of constants added:
- CHAN_ALM_* constants for (later) vin, temp alarm callbacks.
- CHAN_* conversion constants, used in _init_device, partly for RW1C bits

Signed-off-by: Jim Cromie 
Cc: Jean Delvare 
Cc: "Mark M. Hoffman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hwmon: Let the user override the detected Super-I/O device ID

2008-02-08T01:39:42+00:00

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 
Acked-by: Hans de Goede 
Signed-off-by: Mark M. Hoffman

hwmon: VRM is not read from registers

2007-10-10T02:56:32+00:00

The VRM value is not read from chip registers, so there's no need
to update the device data cache before exporting the VRM value to
user-space.

Signed-off-by: Jean Delvare 
Acked-by: Hans de Goede 
Signed-off-by: Mark M. Hoffman

hwmon: Convert from class_device to device

2007-10-10T02:56:30+00:00

Convert from class_device to device for hwmon_device_register/unregister

Signed-off-by: Tony Jones 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kay Sievers 
Signed-off-by: Mark M. Hoffman