summaryrefslogtreecommitdiffstats
path: root/drivers/hwmon/Kconfig
diff options
context:
space:
mode:
authorDavid Brownell <david-b@pacbell.net>2008-05-03 19:33:15 -0700
committerMark M. Hoffman <mhoffman@lightlink.com>2008-07-31 23:44:02 -0400
commit9ebd3d822efeca2e73565516a80373c76ce3fa12 (patch)
tree35947ad745ced49a5bfcd5dc1337ad0a4935d829 /drivers/hwmon/Kconfig
parent01a52397e95a8532c59506691759dba9262d6be7 (diff)
downloadlinux-9ebd3d822efeca2e73565516a80373c76ce3fa12.tar.bz2
hwmon: (lm75) add new-style driver binding
More LM75 updates: - Teach the LM75 driver to use new-style driver binding: * Create a second driver struct, using new-style driver binding methods cribbed from the legacy code. * Add a MODULE_DEVICE_TABLE (for "newER-style binding") * The legacy probe logic delegates its work to this new code. * The legacy driver now uses the name "lm75_legacy". - More careful initialization. Chips are put into 9-bit mode so the current interconversion routines will never fail. - Save the original chip configuration, and restore it on exit. (Among other things, this normally turns off the mode where the chip is constantly sampling ... and thus saves power.) So the new-style code should catch all chips that boards declare, while the legacy code catches others. This particular coexistence strategy may need some work yet ... legacy modes might best be set up explicitly by some tool not unlike "sensors-detect". (Or else completely eradicated...) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Diffstat (limited to 'drivers/hwmon/Kconfig')
-rw-r--r--drivers/hwmon/Kconfig7
1 files changed, 6 insertions, 1 deletions
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 86289c283dc8..c882fd05cf29 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -406,7 +406,12 @@ config SENSORS_LM75
- TelCom (now Microchip) TCN75
- Texas Instruments TMP100, TMP101, TMP75, TMP175, TMP275
- Most of these chips will require a "force" module parameter.
+ This driver supports driver model based binding through board
+ specific I2C device tables.
+
+ It also supports the "legacy" style of driver binding. To use
+ that with some chips which don't replicate LM75 quirks exactly,
+ you may need the "force" module parameter.
This driver can also be built as a module. If so, the module
will be called lm75.