* [GIT PATCH] I2C patches for 2.6.13-rc2 @ 2005-07-12 0:03 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:01 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, lm-sensors Here are some i2c patches that have been in the -mm tree for a while. They fix a number of different bugs. But the majority of this patchest (in diffstat volume) is moving the i2c chip drivers into the hwmon directory. I used your 'dotest' script to acomplish this, but don't know if git registered that these files were just renamed or not. If I should do it a different way, please let me know and I'll regenerate the tree. Please pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/ or from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/ if it isn't synced up yet. The full patch series will sent to the linux-kernel and sensors mailing lists, if anyone wants to see them. thanks, greg k-h Documentation/hwmon/adm1021 | 111 ++ Documentation/hwmon/adm1025 | 51 + Documentation/hwmon/adm1026 | 93 + Documentation/hwmon/adm1031 | 35 Documentation/hwmon/adm9240 | 177 +++ Documentation/hwmon/asb100 | 72 + Documentation/hwmon/ds1621 | 108 ++ Documentation/hwmon/fscher | 169 +++ Documentation/hwmon/gl518sm | 74 + Documentation/hwmon/it87 | 96 ++ Documentation/hwmon/lm63 | 57 + Documentation/hwmon/lm75 | 65 + Documentation/hwmon/lm77 | 22 Documentation/hwmon/lm78 | 82 + Documentation/hwmon/lm80 | 56 + Documentation/hwmon/lm83 | 76 + Documentation/hwmon/lm85 | 221 ++++ Documentation/hwmon/lm87 | 73 + Documentation/hwmon/lm90 | 121 ++ Documentation/hwmon/lm92 | 37 Documentation/hwmon/max1619 | 29 Documentation/hwmon/pc87360 | 189 +++ Documentation/hwmon/sis5595 | 106 ++ Documentation/hwmon/smsc47b397 | 158 +++ Documentation/hwmon/smsc47m1 | 52 + Documentation/hwmon/sysfs-interface | 274 +++++ Documentation/hwmon/userspace-tools | 39 Documentation/hwmon/via686a | 65 + Documentation/hwmon/w83627hf | 66 + Documentation/hwmon/w83781d | 402 ++++++++ Documentation/hwmon/w83l785ts | 39 Documentation/i2c/chips/adm1021 | 111 -- Documentation/i2c/chips/adm1025 | 51 - Documentation/i2c/chips/adm1026 | 93 - Documentation/i2c/chips/adm1031 | 35 Documentation/i2c/chips/adm9240 | 177 --- Documentation/i2c/chips/asb100 | 72 - Documentation/i2c/chips/ds1621 | 108 -- Documentation/i2c/chips/fscher | 169 --- Documentation/i2c/chips/gl518sm | 74 - Documentation/i2c/chips/it87 | 96 -- Documentation/i2c/chips/lm63 | 57 - Documentation/i2c/chips/lm75 | 65 - Documentation/i2c/chips/lm77 | 22 Documentation/i2c/chips/lm78 | 82 - Documentation/i2c/chips/lm80 | 56 - Documentation/i2c/chips/lm83 | 76 - Documentation/i2c/chips/lm85 | 221 ---- Documentation/i2c/chips/lm87 | 73 - Documentation/i2c/chips/lm90 | 121 -- Documentation/i2c/chips/lm92 | 37 Documentation/i2c/chips/max1619 | 29 Documentation/i2c/chips/max6875 | 22 Documentation/i2c/chips/pc87360 | 189 --- Documentation/i2c/chips/sis5595 | 106 -- Documentation/i2c/chips/smsc47b397 | 158 --- Documentation/i2c/chips/smsc47m1 | 52 - Documentation/i2c/chips/via686a | 65 - Documentation/i2c/chips/w83627hf | 66 - Documentation/i2c/chips/w83781d | 402 -------- Documentation/i2c/chips/w83l785ts | 39 Documentation/i2c/dev-interface | 15 Documentation/i2c/sysfs-interface | 274 ----- Documentation/i2c/userspace-tools | 39 Documentation/i2c/writing-clients | 7 arch/arm/Kconfig | 2 arch/h8300/Kconfig | 2 arch/sparc64/Kconfig | 2 drivers/Kconfig | 2 drivers/Makefile | 1 drivers/hwmon/Kconfig | 420 ++++++++ drivers/hwmon/Makefile | 44 drivers/hwmon/adm1021.c | 402 ++++++++ drivers/hwmon/adm1025.c | 577 ++++++++++++ drivers/hwmon/adm1026.c | 1714 ++++++++++++++++++++++++++++++++++++ drivers/hwmon/adm1031.c | 977 ++++++++++++++++++++ drivers/hwmon/adm9240.c | 791 ++++++++++++++++ drivers/hwmon/asb100.c | 1065 ++++++++++++++++++++++ drivers/hwmon/atxp1.c | 361 +++++++ drivers/hwmon/ds1621.c | 341 +++++++ drivers/hwmon/fscher.c | 691 ++++++++++++++ drivers/hwmon/fscpos.c | 641 +++++++++++++ drivers/hwmon/gl518sm.c | 604 ++++++++++++ drivers/hwmon/gl520sm.c | 769 ++++++++++++++++ drivers/hwmon/it87.c | 1184 ++++++++++++++++++++++++ drivers/hwmon/lm63.c | 597 ++++++++++++ drivers/hwmon/lm75.c | 296 ++++++ drivers/hwmon/lm75.h | 49 + drivers/hwmon/lm77.c | 420 ++++++++ drivers/hwmon/lm78.c | 795 ++++++++++++++++ drivers/hwmon/lm80.c | 601 ++++++++++++ drivers/hwmon/lm83.c | 408 ++++++++ drivers/hwmon/lm85.c | 1575 +++++++++++++++++++++++++++++++++ drivers/hwmon/lm87.c | 828 +++++++++++++++++ drivers/hwmon/lm90.c | 655 +++++++++++++ drivers/hwmon/lm92.c | 429 +++++++++ drivers/hwmon/max1619.c | 372 +++++++ drivers/hwmon/pc87360.c | 1348 ++++++++++++++++++++++++++++ drivers/hwmon/sis5595.c | 817 +++++++++++++++++ drivers/hwmon/smsc47b397.c | 352 +++++++ drivers/hwmon/smsc47m1.c | 593 ++++++++++++ drivers/hwmon/via686a.c | 875 ++++++++++++++++++ drivers/hwmon/w83627ehf.c | 846 +++++++++++++++++ drivers/hwmon/w83627hf.c | 1511 +++++++++++++++++++++++++++++++ drivers/hwmon/w83781d.c | 1632 ++++++++++++++++++++++++++++++++++ drivers/hwmon/w83l785ts.c | 328 ++++++ drivers/i2c/algos/i2c-algo-ite.c | 8 drivers/i2c/busses/i2c-i801.c | 4 drivers/i2c/busses/i2c-piix4.c | 2 drivers/i2c/busses/i2c-sis5595.c | 2 drivers/i2c/chips/Kconfig | 415 -------- drivers/i2c/chips/Makefile | 38 drivers/i2c/chips/adm1021.c | 402 -------- drivers/i2c/chips/adm1025.c | 577 ------------ drivers/i2c/chips/adm1026.c | 1714 ------------------------------------ drivers/i2c/chips/adm1031.c | 977 -------------------- drivers/i2c/chips/adm9240.c | 791 ---------------- drivers/i2c/chips/asb100.c | 1065 ---------------------- drivers/i2c/chips/atxp1.c | 361 ------- drivers/i2c/chips/ds1621.c | 341 ------- drivers/i2c/chips/eeprom.c | 3 drivers/i2c/chips/fscher.c | 691 -------------- drivers/i2c/chips/fscpos.c | 641 ------------- drivers/i2c/chips/gl518sm.c | 604 ------------ drivers/i2c/chips/gl520sm.c | 769 ---------------- drivers/i2c/chips/it87.c | 1184 ------------------------ drivers/i2c/chips/lm63.c | 597 ------------ drivers/i2c/chips/lm75.c | 296 ------ drivers/i2c/chips/lm75.h | 49 - drivers/i2c/chips/lm77.c | 420 -------- drivers/i2c/chips/lm78.c | 795 ---------------- drivers/i2c/chips/lm80.c | 601 ------------ drivers/i2c/chips/lm83.c | 408 -------- drivers/i2c/chips/lm85.c | 1575 --------------------------------- drivers/i2c/chips/lm87.c | 828 ----------------- drivers/i2c/chips/lm90.c | 655 ------------- drivers/i2c/chips/lm92.c | 429 --------- drivers/i2c/chips/m41t00.c | 2 drivers/i2c/chips/max1619.c | 372 ------- drivers/i2c/chips/max6875.c | 6 drivers/i2c/chips/pc87360.c | 1348 ---------------------------- drivers/i2c/chips/sis5595.c | 817 ----------------- drivers/i2c/chips/smsc47b397.c | 352 ------- drivers/i2c/chips/smsc47m1.c | 593 ------------ drivers/i2c/chips/tps65010.c | 61 - drivers/i2c/chips/via686a.c | 887 ------------------ drivers/i2c/chips/w83627ehf.c | 846 ----------------- drivers/i2c/chips/w83627hf.c | 1511 ------------------------------- drivers/i2c/chips/w83781d.c | 1632 ---------------------------------- drivers/i2c/chips/w83l785ts.c | 328 ------ drivers/i2c/i2c-core.c | 17 drivers/w1/w1.c | 5 152 files changed, 29226 insertions(+), 29184 deletions(-) ---------- Adrian Bunk: I2C: SENSORS_ATXP1 must select I2C_SENSOR david-b@pacbell.net: I2C: minor I2C doc cleanups I2C: minor TPS6501x cleanups Denis Vlasenko: I2C: Coding style cleanups to via686a Evgeniy Polyakov: w1: fix CRC calculation on bigendian platforms. Jan Veldeman: I2C: Documentation fix Jean Delvare: I2C: Move hwmon drivers (3/3) I2C: Move hwmon drivers (2/3) I2C: Move hwmon drivers (1/3) I2C: Clarify the usage of i2c-dev.h I2C: New max6875 driver may corrupt EEPROMs I2C: m41t00: fix incorrect kfree I2C: Strip trailing whitespace from strings I2C: drop bogus eeprom comment I2C: max6875 Kconfig update I2C: max6875 documentation update Mark M. Hoffman: i2c: make better use of IDR in i2c-core ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [GIT PATCH] I2C patches for 2.6.13-rc2 @ 2005-07-12 0:03 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:03 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, lm-sensors Here are some i2c patches that have been in the -mm tree for a while. They fix a number of different bugs. But the majority of this patchest (in diffstat volume) is moving the i2c chip drivers into the hwmon directory. I used your 'dotest' script to acomplish this, but don't know if git registered that these files were just renamed or not. If I should do it a different way, please let me know and I'll regenerate the tree. Please pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/ or from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/ if it isn't synced up yet. The full patch series will sent to the linux-kernel and sensors mailing lists, if anyone wants to see them. thanks, greg k-h Documentation/hwmon/adm1021 | 111 ++ Documentation/hwmon/adm1025 | 51 + Documentation/hwmon/adm1026 | 93 + Documentation/hwmon/adm1031 | 35 Documentation/hwmon/adm9240 | 177 +++ Documentation/hwmon/asb100 | 72 + Documentation/hwmon/ds1621 | 108 ++ Documentation/hwmon/fscher | 169 +++ Documentation/hwmon/gl518sm | 74 + Documentation/hwmon/it87 | 96 ++ Documentation/hwmon/lm63 | 57 + Documentation/hwmon/lm75 | 65 + Documentation/hwmon/lm77 | 22 Documentation/hwmon/lm78 | 82 + Documentation/hwmon/lm80 | 56 + Documentation/hwmon/lm83 | 76 + Documentation/hwmon/lm85 | 221 ++++ Documentation/hwmon/lm87 | 73 + Documentation/hwmon/lm90 | 121 ++ Documentation/hwmon/lm92 | 37 Documentation/hwmon/max1619 | 29 Documentation/hwmon/pc87360 | 189 +++ Documentation/hwmon/sis5595 | 106 ++ Documentation/hwmon/smsc47b397 | 158 +++ Documentation/hwmon/smsc47m1 | 52 + Documentation/hwmon/sysfs-interface | 274 +++++ Documentation/hwmon/userspace-tools | 39 Documentation/hwmon/via686a | 65 + Documentation/hwmon/w83627hf | 66 + Documentation/hwmon/w83781d | 402 ++++++++ Documentation/hwmon/w83l785ts | 39 Documentation/i2c/chips/adm1021 | 111 -- Documentation/i2c/chips/adm1025 | 51 - Documentation/i2c/chips/adm1026 | 93 - Documentation/i2c/chips/adm1031 | 35 Documentation/i2c/chips/adm9240 | 177 --- Documentation/i2c/chips/asb100 | 72 - Documentation/i2c/chips/ds1621 | 108 -- Documentation/i2c/chips/fscher | 169 --- Documentation/i2c/chips/gl518sm | 74 - Documentation/i2c/chips/it87 | 96 -- Documentation/i2c/chips/lm63 | 57 - Documentation/i2c/chips/lm75 | 65 - Documentation/i2c/chips/lm77 | 22 Documentation/i2c/chips/lm78 | 82 - Documentation/i2c/chips/lm80 | 56 - Documentation/i2c/chips/lm83 | 76 - Documentation/i2c/chips/lm85 | 221 ---- Documentation/i2c/chips/lm87 | 73 - Documentation/i2c/chips/lm90 | 121 -- Documentation/i2c/chips/lm92 | 37 Documentation/i2c/chips/max1619 | 29 Documentation/i2c/chips/max6875 | 22 Documentation/i2c/chips/pc87360 | 189 --- Documentation/i2c/chips/sis5595 | 106 -- Documentation/i2c/chips/smsc47b397 | 158 --- Documentation/i2c/chips/smsc47m1 | 52 - Documentation/i2c/chips/via686a | 65 - Documentation/i2c/chips/w83627hf | 66 - Documentation/i2c/chips/w83781d | 402 -------- Documentation/i2c/chips/w83l785ts | 39 Documentation/i2c/dev-interface | 15 Documentation/i2c/sysfs-interface | 274 ----- Documentation/i2c/userspace-tools | 39 Documentation/i2c/writing-clients | 7 arch/arm/Kconfig | 2 arch/h8300/Kconfig | 2 arch/sparc64/Kconfig | 2 drivers/Kconfig | 2 drivers/Makefile | 1 drivers/hwmon/Kconfig | 420 ++++++++ drivers/hwmon/Makefile | 44 drivers/hwmon/adm1021.c | 402 ++++++++ drivers/hwmon/adm1025.c | 577 ++++++++++++ drivers/hwmon/adm1026.c | 1714 ++++++++++++++++++++++++++++++++++++ drivers/hwmon/adm1031.c | 977 ++++++++++++++++++++ drivers/hwmon/adm9240.c | 791 ++++++++++++++++ drivers/hwmon/asb100.c | 1065 ++++++++++++++++++++++ drivers/hwmon/atxp1.c | 361 +++++++ drivers/hwmon/ds1621.c | 341 +++++++ drivers/hwmon/fscher.c | 691 ++++++++++++++ drivers/hwmon/fscpos.c | 641 +++++++++++++ drivers/hwmon/gl518sm.c | 604 ++++++++++++ drivers/hwmon/gl520sm.c | 769 ++++++++++++++++ drivers/hwmon/it87.c | 1184 ++++++++++++++++++++++++ drivers/hwmon/lm63.c | 597 ++++++++++++ drivers/hwmon/lm75.c | 296 ++++++ drivers/hwmon/lm75.h | 49 + drivers/hwmon/lm77.c | 420 ++++++++ drivers/hwmon/lm78.c | 795 ++++++++++++++++ drivers/hwmon/lm80.c | 601 ++++++++++++ drivers/hwmon/lm83.c | 408 ++++++++ drivers/hwmon/lm85.c | 1575 +++++++++++++++++++++++++++++++++ drivers/hwmon/lm87.c | 828 +++++++++++++++++ drivers/hwmon/lm90.c | 655 +++++++++++++ drivers/hwmon/lm92.c | 429 +++++++++ drivers/hwmon/max1619.c | 372 +++++++ drivers/hwmon/pc87360.c | 1348 ++++++++++++++++++++++++++++ drivers/hwmon/sis5595.c | 817 +++++++++++++++++ drivers/hwmon/smsc47b397.c | 352 +++++++ drivers/hwmon/smsc47m1.c | 593 ++++++++++++ drivers/hwmon/via686a.c | 875 ++++++++++++++++++ drivers/hwmon/w83627ehf.c | 846 +++++++++++++++++ drivers/hwmon/w83627hf.c | 1511 +++++++++++++++++++++++++++++++ drivers/hwmon/w83781d.c | 1632 ++++++++++++++++++++++++++++++++++ drivers/hwmon/w83l785ts.c | 328 ++++++ drivers/i2c/algos/i2c-algo-ite.c | 8 drivers/i2c/busses/i2c-i801.c | 4 drivers/i2c/busses/i2c-piix4.c | 2 drivers/i2c/busses/i2c-sis5595.c | 2 drivers/i2c/chips/Kconfig | 415 -------- drivers/i2c/chips/Makefile | 38 drivers/i2c/chips/adm1021.c | 402 -------- drivers/i2c/chips/adm1025.c | 577 ------------ drivers/i2c/chips/adm1026.c | 1714 ------------------------------------ drivers/i2c/chips/adm1031.c | 977 -------------------- drivers/i2c/chips/adm9240.c | 791 ---------------- drivers/i2c/chips/asb100.c | 1065 ---------------------- drivers/i2c/chips/atxp1.c | 361 ------- drivers/i2c/chips/ds1621.c | 341 ------- drivers/i2c/chips/eeprom.c | 3 drivers/i2c/chips/fscher.c | 691 -------------- drivers/i2c/chips/fscpos.c | 641 ------------- drivers/i2c/chips/gl518sm.c | 604 ------------ drivers/i2c/chips/gl520sm.c | 769 ---------------- drivers/i2c/chips/it87.c | 1184 ------------------------ drivers/i2c/chips/lm63.c | 597 ------------ drivers/i2c/chips/lm75.c | 296 ------ drivers/i2c/chips/lm75.h | 49 - drivers/i2c/chips/lm77.c | 420 -------- drivers/i2c/chips/lm78.c | 795 ---------------- drivers/i2c/chips/lm80.c | 601 ------------ drivers/i2c/chips/lm83.c | 408 -------- drivers/i2c/chips/lm85.c | 1575 --------------------------------- drivers/i2c/chips/lm87.c | 828 ----------------- drivers/i2c/chips/lm90.c | 655 ------------- drivers/i2c/chips/lm92.c | 429 --------- drivers/i2c/chips/m41t00.c | 2 drivers/i2c/chips/max1619.c | 372 ------- drivers/i2c/chips/max6875.c | 6 drivers/i2c/chips/pc87360.c | 1348 ---------------------------- drivers/i2c/chips/sis5595.c | 817 ----------------- drivers/i2c/chips/smsc47b397.c | 352 ------- drivers/i2c/chips/smsc47m1.c | 593 ------------ drivers/i2c/chips/tps65010.c | 61 - drivers/i2c/chips/via686a.c | 887 ------------------ drivers/i2c/chips/w83627ehf.c | 846 ----------------- drivers/i2c/chips/w83627hf.c | 1511 ------------------------------- drivers/i2c/chips/w83781d.c | 1632 ---------------------------------- drivers/i2c/chips/w83l785ts.c | 328 ------ drivers/i2c/i2c-core.c | 17 drivers/w1/w1.c | 5 152 files changed, 29226 insertions(+), 29184 deletions(-) ---------- Adrian Bunk: I2C: SENSORS_ATXP1 must select I2C_SENSOR david-b@pacbell.net: I2C: minor I2C doc cleanups I2C: minor TPS6501x cleanups Denis Vlasenko: I2C: Coding style cleanups to via686a Evgeniy Polyakov: w1: fix CRC calculation on bigendian platforms. Jan Veldeman: I2C: Documentation fix Jean Delvare: I2C: Move hwmon drivers (3/3) I2C: Move hwmon drivers (2/3) I2C: Move hwmon drivers (1/3) I2C: Clarify the usage of i2c-dev.h I2C: New max6875 driver may corrupt EEPROMs I2C: m41t00: fix incorrect kfree I2C: Strip trailing whitespace from strings I2C: drop bogus eeprom comment I2C: max6875 Kconfig update I2C: max6875 documentation update Mark M. Hoffman: i2c: make better use of IDR in i2c-core ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: max6875 documentation update 2005-07-12 0:03 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: max6875 documentation update Here is a proposed documentation update for the new max6875 i2c chip driver. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 089bd86632769051f15cd7387eebe126d18f151f tree 57637f07d7cb28543db158d2457804e968d2a021 parent 9ab1ee2ab7d65979c0f14a60ee1f29f8988f5811 author Jean Delvare <khali@linux-fr.org> Thu, 23 Jun 2005 23:37:53 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 Documentation/i2c/chips/max6875 | 22 +++++++++++++++++----- 1 files changed, 17 insertions(+), 5 deletions(-) diff --git a/Documentation/i2c/chips/max6875 b/Documentation/i2c/chips/max6875 --- a/Documentation/i2c/chips/max6875 +++ b/Documentation/i2c/chips/max6875 @@ -2,10 +2,10 @@ Kernel driver max6875 ===================== Supported chips: - * Maxim max6874, max6875 - Prefixes: 'max6875' + * Maxim MAX6874, MAX6875 + Prefix: 'max6875' Addresses scanned: 0x50, 0x52 - Datasheets: + Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf Author: Ben Gardner <bgardner@wabtec.com> @@ -23,14 +23,26 @@ Module Parameters Description ----------- -The MAXIM max6875 is a EEPROM-programmable power-supply sequencer/supervisor. +The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor. It provides timed outputs that can be used as a watchdog, if properly wired. It also provides 512 bytes of user EEPROM. -At reset, the max6875 reads the configuration eeprom into its configuration +At reset, the MAX6875 reads the configuration EEPROM into its configuration registers. The chip then begins to operate according to the values in the registers. +The Maxim MAX6874 is a similar, mostly compatible device, with more intputs +and outputs: + + vin gpi vout +MAX6874 6 4 8 +MAX6875 4 3 5 + +MAX6874 chips can have four different addresses (as opposed to only two for +the MAX6875). The additional addresses (0x54 and 0x56) are not probed by +this driver by default, but the probe module parameter can be used if +needed. + See the datasheet for details on how to program the EEPROM. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: max6875 documentation update @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: max6875 documentation update Here is a proposed documentation update for the new max6875 i2c chip driver. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 089bd86632769051f15cd7387eebe126d18f151f tree 57637f07d7cb28543db158d2457804e968d2a021 parent 9ab1ee2ab7d65979c0f14a60ee1f29f8988f5811 author Jean Delvare <khali@linux-fr.org> Thu, 23 Jun 2005 23:37:53 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 Documentation/i2c/chips/max6875 | 22 +++++++++++++++++----- 1 files changed, 17 insertions(+), 5 deletions(-) diff --git a/Documentation/i2c/chips/max6875 b/Documentation/i2c/chips/max6875 --- a/Documentation/i2c/chips/max6875 +++ b/Documentation/i2c/chips/max6875 @@ -2,10 +2,10 @@ Kernel driver max6875 ========== Supported chips: - * Maxim max6874, max6875 - Prefixes: 'max6875' + * Maxim MAX6874, MAX6875 + Prefix: 'max6875' Addresses scanned: 0x50, 0x52 - Datasheets: + Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf Author: Ben Gardner <bgardner@wabtec.com> @@ -23,14 +23,26 @@ Module Parameters Description ----------- -The MAXIM max6875 is a EEPROM-programmable power-supply sequencer/supervisor. +The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor. It provides timed outputs that can be used as a watchdog, if properly wired. It also provides 512 bytes of user EEPROM. -At reset, the max6875 reads the configuration eeprom into its configuration +At reset, the MAX6875 reads the configuration EEPROM into its configuration registers. The chip then begins to operate according to the values in the registers. +The Maxim MAX6874 is a similar, mostly compatible device, with more intputs +and outputs: + + vin gpi vout +MAX6874 6 4 8 +MAX6875 4 3 5 + +MAX6874 chips can have four different addresses (as opposed to only two for +the MAX6875). The additional addresses (0x54 and 0x56) are not probed by +this driver by default, but the probe module parameter can be used if +needed. + See the datasheet for details on how to program the EEPROM. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: max6875 Kconfig update 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:03 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: max6875 Kconfig update Here is a proposed Kconfig update for the new max6875 i2c chip driver. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 2146fec20c38d926f0d88413977f941f42a14588 tree daaf87a4ec6e6c70c9e1be8b2bd09257b3be092f parent 089bd86632769051f15cd7387eebe126d18f151f author Jean Delvare <khali@linux-fr.org> Thu, 23 Jun 2005 23:41:39 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/Kconfig | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -519,13 +519,16 @@ config SENSORS_M41T00 will be called m41t00. config SENSORS_MAX6875 - tristate "MAXIM MAX6875 Power supply supervisor" + tristate "Maxim MAX6875 Power supply supervisor" depends on I2C && EXPERIMENTAL help - If you say yes here you get support for the MAX6875 - EEPROM-Programmable, Hex/Quad, Power-Suppy Sequencers/Supervisors. + If you say yes here you get support for the Maxim MAX6875 + EEPROM-programmable, quad power-supply sequencer/supervisor. - This provides a interface to program the EEPROM and reset the chip. + This provides an interface to program the EEPROM and reset the chip. + + This driver also supports the Maxim MAX6874 hex power-supply + sequencer/supervisor if found at a compatible address. This driver can also be built as a module. If so, the module will be called max6875. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: max6875 Kconfig update @ 2005-07-12 0:03 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:03 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: max6875 Kconfig update Here is a proposed Kconfig update for the new max6875 i2c chip driver. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 2146fec20c38d926f0d88413977f941f42a14588 tree daaf87a4ec6e6c70c9e1be8b2bd09257b3be092f parent 089bd86632769051f15cd7387eebe126d18f151f author Jean Delvare <khali@linux-fr.org> Thu, 23 Jun 2005 23:41:39 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/Kconfig | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -519,13 +519,16 @@ config SENSORS_M41T00 will be called m41t00. config SENSORS_MAX6875 - tristate "MAXIM MAX6875 Power supply supervisor" + tristate "Maxim MAX6875 Power supply supervisor" depends on I2C && EXPERIMENTAL help - If you say yes here you get support for the MAX6875 - EEPROM-Programmable, Hex/Quad, Power-Suppy Sequencers/Supervisors. + If you say yes here you get support for the Maxim MAX6875 + EEPROM-programmable, quad power-supply sequencer/supervisor. - This provides a interface to program the EEPROM and reset the chip. + This provides an interface to program the EEPROM and reset the chip. + + This driver also supports the Maxim MAX6874 hex power-supply + sequencer/supervisor if found at a compatible address. This driver can also be built as a module. If so, the module will be called max6875. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: drop bogus eeprom comment 2005-07-12 0:03 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: drop bogus eeprom comment This simple patch drops an out-of-date comment in the eeprom i2c chip driver. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 2db32767874fe53faff4f80de878ca19927efc1f tree 4ac3024bd4e29e7770f96244b386429d991c58f7 parent a0920e10438e9fe8b22aba607083347c84458ed8 author Jean Delvare <khali@linux-fr.org> Thu, 23 Jun 2005 23:43:00 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/eeprom.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/chips/eeprom.c b/drivers/i2c/chips/eeprom.c --- a/drivers/i2c/chips/eeprom.c +++ b/drivers/i2c/chips/eeprom.c @@ -173,9 +173,6 @@ int eeprom_detect(struct i2c_adapter *ad | I2C_FUNC_SMBUS_BYTE)) goto exit; - /* OK. For now, we presume we have a valid client. We now create the - client structure, even though we cannot fill it completely yet. - But it allows us to access eeprom_{read,write}_value. */ if (!(data = kmalloc(sizeof(struct eeprom_data), GFP_KERNEL))) { err = -ENOMEM; goto exit; ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: drop bogus eeprom comment @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: drop bogus eeprom comment This simple patch drops an out-of-date comment in the eeprom i2c chip driver. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 2db32767874fe53faff4f80de878ca19927efc1f tree 4ac3024bd4e29e7770f96244b386429d991c58f7 parent a0920e10438e9fe8b22aba607083347c84458ed8 author Jean Delvare <khali@linux-fr.org> Thu, 23 Jun 2005 23:43:00 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/eeprom.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/chips/eeprom.c b/drivers/i2c/chips/eeprom.c --- a/drivers/i2c/chips/eeprom.c +++ b/drivers/i2c/chips/eeprom.c @@ -173,9 +173,6 @@ int eeprom_detect(struct i2c_adapter *ad | I2C_FUNC_SMBUS_BYTE)) goto exit; - /* OK. For now, we presume we have a valid client. We now create the - client structure, even though we cannot fill it completely yet. - But it allows us to access eeprom_{read,write}_value. */ if (!(data = kmalloc(sizeof(struct eeprom_data), GFP_KERNEL))) { err = -ENOMEM; goto exit; ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: Strip trailing whitespace from strings 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: Strip trailing whitespace from strings Here is a simple patch originally from Denis Vlasenko, which strips a useless trailing whitespace from 8 strings in 4 i2c drivers. Please apply, thanks. From: Denis Vlasenko <vda@ilport.com.ua> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 541e6a02768404efb06bd1ea5f33d614732f41fc tree 933f4e7b38580c69e61b8a0002d4e5c129c5abaa parent 65fc50e50ff9f8b82c3756eccd7e7db6a267ffe9 author Jean Delvare <khali@linux-fr.org> Thu, 23 Jun 2005 22:18:08 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/algos/i2c-algo-ite.c | 8 ++++---- drivers/i2c/busses/i2c-i801.c | 4 ++-- drivers/i2c/busses/i2c-piix4.c | 2 +- drivers/i2c/busses/i2c-sis5595.c | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/i2c/algos/i2c-algo-ite.c b/drivers/i2c/algos/i2c-algo-ite.c --- a/drivers/i2c/algos/i2c-algo-ite.c +++ b/drivers/i2c/algos/i2c-algo-ite.c @@ -208,7 +208,7 @@ static int test_bus(struct i2c_algo_iic_ goto bailout; } sdalo(adap); - printk("test_bus:1 scl: %d sda: %d \n",getscl(adap), + printk("test_bus:1 scl: %d sda: %d\n", getscl(adap), getsda(adap)); if ( 0 != getsda(adap) ) { printk("test_bus: %s SDA stuck high!\n",name); @@ -221,7 +221,7 @@ static int test_bus(struct i2c_algo_iic_ goto bailout; } sdahi(adap); - printk("test_bus:2 scl: %d sda: %d \n",getscl(adap), + printk("test_bus:2 scl: %d sda: %d\n", getscl(adap), getsda(adap)); if ( 0 == getsda(adap) ) { printk("test_bus: %s SDA stuck low!\n",name); @@ -234,7 +234,7 @@ static int test_bus(struct i2c_algo_iic_ goto bailout; } scllo(adap); - printk("test_bus:3 scl: %d sda: %d \n",getscl(adap), + printk("test_bus:3 scl: %d sda: %d\n", getscl(adap), getsda(adap)); if ( 0 != getscl(adap) ) { @@ -247,7 +247,7 @@ static int test_bus(struct i2c_algo_iic_ goto bailout; } sclhi(adap); - printk("test_bus:4 scl: %d sda: %d \n",getscl(adap), + printk("test_bus:4 scl: %d sda: %d\n", getscl(adap), getsda(adap)); if ( 0 == getscl(adap) ) { printk("test_bus: %s SCL stuck low!\n",name); diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c --- a/drivers/i2c/busses/i2c-i801.c +++ b/drivers/i2c/busses/i2c-i801.c @@ -194,7 +194,7 @@ static int i801_transaction(void) /* Make sure the SMBus host is ready to start transmitting */ /* 0x1f = Failed, Bus_Err, Dev_Err, Intr, Host_Busy */ if ((temp = (0x1f & inb_p(SMBHSTSTS))) != 0x00) { - dev_dbg(&I801_dev->dev, "SMBus busy (%02x). Resetting... \n", + dev_dbg(&I801_dev->dev, "SMBus busy (%02x). Resetting...\n", temp); outb_p(temp, SMBHSTSTS); if ((temp = (0x1f & inb_p(SMBHSTSTS))) != 0x00) { @@ -315,7 +315,7 @@ static int i801_block_transaction(union } if (temp & errmask) { dev_dbg(&I801_dev->dev, "SMBus busy (%02x). " - "Resetting... \n", temp); + "Resetting...\n", temp); outb_p(temp, SMBHSTSTS); if (((temp = inb_p(SMBHSTSTS)) & errmask) != 0x00) { dev_err(&I801_dev->dev, diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c --- a/drivers/i2c/busses/i2c-piix4.c +++ b/drivers/i2c/busses/i2c-piix4.c @@ -243,7 +243,7 @@ static int piix4_transaction(void) /* Make sure the SMBus host is ready to start transmitting */ if ((temp = inb_p(SMBHSTSTS)) != 0x00) { dev_dbg(&piix4_adapter.dev, "SMBus busy (%02x). " - "Resetting... \n", temp); + "Resetting...\n", temp); outb_p(temp, SMBHSTSTS); if ((temp = inb_p(SMBHSTSTS)) != 0x00) { dev_err(&piix4_adapter.dev, "Failed! (%02x)\n", temp); diff --git a/drivers/i2c/busses/i2c-sis5595.c b/drivers/i2c/busses/i2c-sis5595.c --- a/drivers/i2c/busses/i2c-sis5595.c +++ b/drivers/i2c/busses/i2c-sis5595.c @@ -228,7 +228,7 @@ static int sis5595_transaction(struct i2 /* Make sure the SMBus host is ready to start transmitting */ temp = sis5595_read(SMB_STS_LO) + (sis5595_read(SMB_STS_HI) << 8); if (temp != 0x00) { - dev_dbg(&adap->dev, "SMBus busy (%04x). Resetting... \n", temp); + dev_dbg(&adap->dev, "SMBus busy (%04x). Resetting...\n", temp); sis5595_write(SMB_STS_LO, temp & 0xff); sis5595_write(SMB_STS_HI, temp >> 8); if ((temp = sis5595_read(SMB_STS_LO) + (sis5595_read(SMB_STS_HI) << 8)) != 0x00) { ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: Strip trailing whitespace from strings @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: Strip trailing whitespace from strings Here is a simple patch originally from Denis Vlasenko, which strips a useless trailing whitespace from 8 strings in 4 i2c drivers. Please apply, thanks. From: Denis Vlasenko <vda@ilport.com.ua> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 541e6a02768404efb06bd1ea5f33d614732f41fc tree 933f4e7b38580c69e61b8a0002d4e5c129c5abaa parent 65fc50e50ff9f8b82c3756eccd7e7db6a267ffe9 author Jean Delvare <khali@linux-fr.org> Thu, 23 Jun 2005 22:18:08 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/algos/i2c-algo-ite.c | 8 ++++---- drivers/i2c/busses/i2c-i801.c | 4 ++-- drivers/i2c/busses/i2c-piix4.c | 2 +- drivers/i2c/busses/i2c-sis5595.c | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/i2c/algos/i2c-algo-ite.c b/drivers/i2c/algos/i2c-algo-ite.c --- a/drivers/i2c/algos/i2c-algo-ite.c +++ b/drivers/i2c/algos/i2c-algo-ite.c @@ -208,7 +208,7 @@ static int test_bus(struct i2c_algo_iic_ goto bailout; } sdalo(adap); - printk("test_bus:1 scl: %d sda: %d \n",getscl(adap), + printk("test_bus:1 scl: %d sda: %d\n", getscl(adap), getsda(adap)); if ( 0 != getsda(adap) ) { printk("test_bus: %s SDA stuck high!\n",name); @@ -221,7 +221,7 @@ static int test_bus(struct i2c_algo_iic_ goto bailout; } sdahi(adap); - printk("test_bus:2 scl: %d sda: %d \n",getscl(adap), + printk("test_bus:2 scl: %d sda: %d\n", getscl(adap), getsda(adap)); if ( 0 = getsda(adap) ) { printk("test_bus: %s SDA stuck low!\n",name); @@ -234,7 +234,7 @@ static int test_bus(struct i2c_algo_iic_ goto bailout; } scllo(adap); - printk("test_bus:3 scl: %d sda: %d \n",getscl(adap), + printk("test_bus:3 scl: %d sda: %d\n", getscl(adap), getsda(adap)); if ( 0 != getscl(adap) ) { @@ -247,7 +247,7 @@ static int test_bus(struct i2c_algo_iic_ goto bailout; } sclhi(adap); - printk("test_bus:4 scl: %d sda: %d \n",getscl(adap), + printk("test_bus:4 scl: %d sda: %d\n", getscl(adap), getsda(adap)); if ( 0 = getscl(adap) ) { printk("test_bus: %s SCL stuck low!\n",name); diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c --- a/drivers/i2c/busses/i2c-i801.c +++ b/drivers/i2c/busses/i2c-i801.c @@ -194,7 +194,7 @@ static int i801_transaction(void) /* Make sure the SMBus host is ready to start transmitting */ /* 0x1f = Failed, Bus_Err, Dev_Err, Intr, Host_Busy */ if ((temp = (0x1f & inb_p(SMBHSTSTS))) != 0x00) { - dev_dbg(&I801_dev->dev, "SMBus busy (%02x). Resetting... \n", + dev_dbg(&I801_dev->dev, "SMBus busy (%02x). Resetting...\n", temp); outb_p(temp, SMBHSTSTS); if ((temp = (0x1f & inb_p(SMBHSTSTS))) != 0x00) { @@ -315,7 +315,7 @@ static int i801_block_transaction(union } if (temp & errmask) { dev_dbg(&I801_dev->dev, "SMBus busy (%02x). " - "Resetting... \n", temp); + "Resetting...\n", temp); outb_p(temp, SMBHSTSTS); if (((temp = inb_p(SMBHSTSTS)) & errmask) != 0x00) { dev_err(&I801_dev->dev, diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c --- a/drivers/i2c/busses/i2c-piix4.c +++ b/drivers/i2c/busses/i2c-piix4.c @@ -243,7 +243,7 @@ static int piix4_transaction(void) /* Make sure the SMBus host is ready to start transmitting */ if ((temp = inb_p(SMBHSTSTS)) != 0x00) { dev_dbg(&piix4_adapter.dev, "SMBus busy (%02x). " - "Resetting... \n", temp); + "Resetting...\n", temp); outb_p(temp, SMBHSTSTS); if ((temp = inb_p(SMBHSTSTS)) != 0x00) { dev_err(&piix4_adapter.dev, "Failed! (%02x)\n", temp); diff --git a/drivers/i2c/busses/i2c-sis5595.c b/drivers/i2c/busses/i2c-sis5595.c --- a/drivers/i2c/busses/i2c-sis5595.c +++ b/drivers/i2c/busses/i2c-sis5595.c @@ -228,7 +228,7 @@ static int sis5595_transaction(struct i2 /* Make sure the SMBus host is ready to start transmitting */ temp = sis5595_read(SMB_STS_LO) + (sis5595_read(SMB_STS_HI) << 8); if (temp != 0x00) { - dev_dbg(&adap->dev, "SMBus busy (%04x). Resetting... \n", temp); + dev_dbg(&adap->dev, "SMBus busy (%04x). Resetting...\n", temp); sis5595_write(SMB_STS_LO, temp & 0xff); sis5595_write(SMB_STS_HI, temp >> 8); if ((temp = sis5595_read(SMB_STS_LO) + (sis5595_read(SMB_STS_HI) << 8)) != 0x00) { ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: m41t00: fix incorrect kfree 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: m41t00: fix incorrect kfree Here is a simple path fixing an incorrect kfree in the m41t00 i2c chip driver. The current code happens to work by accident, but the freed pointer isn't the one which was allocated in the first place, which could cause problems later. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 5da69ba42aa42a479c0f5d8cb8351ebb6b51c12e tree 3a0f32c3fbc961bb5f6b39c22c573fa8acd7c443 parent 2146fec20c38d926f0d88413977f941f42a14588 author Jean Delvare <khali@linux-fr.org> Fri, 01 Jul 2005 14:28:15 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/m41t00.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/chips/m41t00.c b/drivers/i2c/chips/m41t00.c --- a/drivers/i2c/chips/m41t00.c +++ b/drivers/i2c/chips/m41t00.c @@ -207,7 +207,7 @@ m41t00_detach(struct i2c_client *client) int rc; if ((rc = i2c_detach_client(client)) == 0) { - kfree(i2c_get_clientdata(client)); + kfree(client); tasklet_kill(&m41t00_tasklet); } return rc; ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: m41t00: fix incorrect kfree @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: m41t00: fix incorrect kfree Here is a simple path fixing an incorrect kfree in the m41t00 i2c chip driver. The current code happens to work by accident, but the freed pointer isn't the one which was allocated in the first place, which could cause problems later. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 5da69ba42aa42a479c0f5d8cb8351ebb6b51c12e tree 3a0f32c3fbc961bb5f6b39c22c573fa8acd7c443 parent 2146fec20c38d926f0d88413977f941f42a14588 author Jean Delvare <khali@linux-fr.org> Fri, 01 Jul 2005 14:28:15 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/m41t00.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/chips/m41t00.c b/drivers/i2c/chips/m41t00.c --- a/drivers/i2c/chips/m41t00.c +++ b/drivers/i2c/chips/m41t00.c @@ -207,7 +207,7 @@ m41t00_detach(struct i2c_client *client) int rc; if ((rc = i2c_detach_client(client)) = 0) { - kfree(i2c_get_clientdata(client)); + kfree(client); tasklet_kill(&m41t00_tasklet); } return rc; ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: Coding style cleanups to via686a 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: vda [PATCH] I2C: Coding style cleanups to via686a On Wednesday 22 June 2005 08:17, Greg KH wrote: > [PATCH] I2C: Coding style cleanups to via686a > > The via686a hardware monitoring driver has infamous coding style at the > moment. I'd like to clean up the mess before I start working on other > changes to this driver. Is the following patch acceptable? No code > change, only coding style (indentation, alignments, trailing white > space, a few parentheses and a typo). > > Signed-off-by: Jean Delvare <khali@linux-fr.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Nice. You missed some. This one is on top of your patch: Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 6328c0e163abfce679b1beffb166f72900bf0a22 tree d5fa7087c5d18b12bd1b93797de2277bddcb6300 parent 200d481f28be4522464bb849dd0eb5f8cb6be781 author Denis Vlasenko <vda@ilport.com.ua> Wed, 22 Jun 2005 10:25:13 +0300 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/via686a.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/chips/via686a.c b/drivers/i2c/chips/via686a.c --- a/drivers/i2c/chips/via686a.c +++ b/drivers/i2c/chips/via686a.c @@ -1,9 +1,9 @@ /* via686a.c - Part of lm_sensors, Linux kernel modules - for hardware monitoring + for hardware monitoring Copyright (c) 1998 - 2002 Frodo Looijaard <frodol@dds.nl>, - Kyösti Mälkki <kmalkki@cc.hut.fi>, + Kyösti Mälkki <kmalkki@cc.hut.fi>, Mark Studebaker <mdsxyz123@yahoo.com>, and Bob Dougherty <bobd@stanford.edu> (Some conversion-factor data were contributed by Jonathan Teh Soon Yew @@ -171,18 +171,18 @@ static inline u8 FAN_TO_REG(long rpm, in /******** TEMP CONVERSIONS (Bob Dougherty) *********/ /* linear fits from HWMon.cpp (Copyright 1998-2000 Jonathan Teh Soon Yew) if(temp<169) - return double(temp)*0.427-32.08; + return double(temp)*0.427-32.08; else if(temp>=169 && temp<=202) - return double(temp)*0.582-58.16; + return double(temp)*0.582-58.16; else - return double(temp)*0.924-127.33; + return double(temp)*0.924-127.33; A fifth-order polynomial fits the unofficial data (provided by Alex van Kaam <darkside@chello.nl>) a bit better. It also give more reasonable numbers on my machine (ie. they agree with what my BIOS tells me). Here's the fifth-order fit to the 8-bit data: temp = 1.625093e-10*val^5 - 1.001632e-07*val^4 + 2.457653e-05*val^3 - - 2.967619e-03*val^2 + 2.175144e-01*val - 7.090067e+0. + 2.967619e-03*val^2 + 2.175144e-01*val - 7.090067e+0. (2000-10-25- RFD: thanks to Uwe Andersen <uandersen@mayah.com> for finding my typos in this formula!) ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: Coding style cleanups to via686a @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: vda [PATCH] I2C: Coding style cleanups to via686a On Wednesday 22 June 2005 08:17, Greg KH wrote: > [PATCH] I2C: Coding style cleanups to via686a > > The via686a hardware monitoring driver has infamous coding style at the > moment. I'd like to clean up the mess before I start working on other > changes to this driver. Is the following patch acceptable? No code > change, only coding style (indentation, alignments, trailing white > space, a few parentheses and a typo). > > Signed-off-by: Jean Delvare <khali@linux-fr.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Nice. You missed some. This one is on top of your patch: Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 6328c0e163abfce679b1beffb166f72900bf0a22 tree d5fa7087c5d18b12bd1b93797de2277bddcb6300 parent 200d481f28be4522464bb849dd0eb5f8cb6be781 author Denis Vlasenko <vda@ilport.com.ua> Wed, 22 Jun 2005 10:25:13 +0300 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/via686a.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/chips/via686a.c b/drivers/i2c/chips/via686a.c --- a/drivers/i2c/chips/via686a.c +++ b/drivers/i2c/chips/via686a.c @@ -1,9 +1,9 @@ /* via686a.c - Part of lm_sensors, Linux kernel modules - for hardware monitoring + for hardware monitoring Copyright (c) 1998 - 2002 Frodo Looijaard <frodol@dds.nl>, - Ky?sti M?lkki <kmalkki@cc.hut.fi>, + Ky?sti M?lkki <kmalkki@cc.hut.fi>, Mark Studebaker <mdsxyz123@yahoo.com>, and Bob Dougherty <bobd@stanford.edu> (Some conversion-factor data were contributed by Jonathan Teh Soon Yew @@ -171,18 +171,18 @@ static inline u8 FAN_TO_REG(long rpm, in /******** TEMP CONVERSIONS (Bob Dougherty) *********/ /* linear fits from HWMon.cpp (Copyright 1998-2000 Jonathan Teh Soon Yew) if(temp<169) - return double(temp)*0.427-32.08; + return double(temp)*0.427-32.08; else if(temp>\x169 && temp< 2) - return double(temp)*0.582-58.16; + return double(temp)*0.582-58.16; else - return double(temp)*0.924-127.33; + return double(temp)*0.924-127.33; A fifth-order polynomial fits the unofficial data (provided by Alex van Kaam <darkside@chello.nl>) a bit better. It also give more reasonable numbers on my machine (ie. they agree with what my BIOS tells me). Here's the fifth-order fit to the 8-bit data: temp = 1.625093e-10*val^5 - 1.001632e-07*val^4 + 2.457653e-05*val^3 - - 2.967619e-03*val^2 + 2.175144e-01*val - 7.090067e+0. + 2.967619e-03*val^2 + 2.175144e-01*val - 7.090067e+0. (2000-10-25- RFD: thanks to Uwe Andersen <uandersen@mayah.com> for finding my typos in this formula!) ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: minor TPS6501x cleanups 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: david-b [PATCH] I2C: minor TPS6501x cleanups This includes various small cleanups and fixes to the TPS 6501x driver that came mostly from review feedback by Jean Delvare; thanks Jean! Also some goofy whitespace gets fixed. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 65fc50e50ff9f8b82c3756eccd7e7db6a267ffe9 tree b78c1f954841ceb64732ebf355dc070b5ce79094 parent 6328c0e163abfce679b1beffb166f72900bf0a22 author david-b@pacbell.net <david-b@pacbell.net> Wed, 29 Jun 2005 07:13:00 -0700 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/Kconfig | 1 - drivers/i2c/chips/tps65010.c | 61 ++++++++++++++++++++---------------------- 2 files changed, 29 insertions(+), 33 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -509,7 +509,6 @@ config TPS65010 This driver can also be built as a module. If so, the module will be called tps65010. - config SENSORS_M41T00 tristate "ST M41T00 RTC chip" depends on I2C && PPC32 diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c --- a/drivers/i2c/chips/tps65010.c +++ b/drivers/i2c/chips/tps65010.c @@ -18,7 +18,6 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ -#undef DEBUG #include <linux/config.h> #include <linux/kernel.h> @@ -49,11 +48,7 @@ MODULE_DESCRIPTION("TPS6501x Power Management Driver"); MODULE_LICENSE("GPL"); -/* only two addresses possible */ -#define TPS_BASE 0x48 -static unsigned short normal_i2c[] = { - TPS_BASE, - I2C_CLIENT_END }; +static unsigned short normal_i2c[] = { 0x48, /* 0x49, */ I2C_CLIENT_END }; static unsigned short normal_i2c_range[] = { I2C_CLIENT_END }; I2C_CLIENT_INSMOD; @@ -102,7 +97,7 @@ struct tps65010 { u8 chgstatus, regstatus, chgconf; u8 nmask1, nmask2; - /* plus four GPIOs, probably used to switch power */ + /* not currently tracking GPIO state */ }; #define POWER_POLL_DELAY msecs_to_jiffies(800) @@ -135,7 +130,7 @@ static void dbg_regstat(char *buf, size_ (regstatus & TPS_REG_COVER) ? " uncover" : "", (regstatus & TPS_REG_UVLO) ? " UVLO" : "", (regstatus & TPS_REG_NO_CHG) ? " NO_CHG" : "", - (regstatus & TPS_REG_PG_LD02) ? " ld01_bad" : "", + (regstatus & TPS_REG_PG_LD02) ? " ld02_bad" : "", (regstatus & TPS_REG_PG_LD01) ? " ld01_bad" : "", (regstatus & TPS_REG_PG_MAIN) ? " main_bad" : "", (regstatus & TPS_REG_PG_CORE) ? " core_bad" : ""); @@ -143,7 +138,7 @@ static void dbg_regstat(char *buf, size_ static void dbg_chgconf(int por, char *buf, size_t len, u8 chgconfig) { - char *hibit; + const char *hibit; if (por) hibit = (chgconfig & TPS_CHARGE_POR) @@ -295,7 +290,7 @@ static int dbg_show(struct seq_file *s, seq_printf(s, "defgpio %02x mask3 %02x\n", value, v2); for (i = 0; i < 4; i++) { - if (value & (1 << (4 +i))) + if (value & (1 << (4 + i))) seq_printf(s, " gpio%d-out %s\n", i + 1, (value & (1 << i)) ? "low" : "hi "); else @@ -481,7 +476,7 @@ static int __exit tps65010_detach_client debugfs_remove(tps->file); if (i2c_detach_client(client) == 0) kfree(tps); - the_tps = 0; + the_tps = NULL; return 0; } @@ -514,7 +509,6 @@ tps65010_probe(struct i2c_adapter *bus, INIT_WORK(&tps->work, tps65010_work, tps); tps->irq = -1; tps->client.addr = address; - i2c_set_clientdata(&tps->client, tps); tps->client.adapter = bus; tps->client.driver = &tps65010_driver; strlcpy(tps->client.name, DRIVER_NAME, I2C_NAME_SIZE); @@ -523,9 +517,7 @@ tps65010_probe(struct i2c_adapter *bus, if (status < 0) { dev_dbg(&bus->dev, "can't attach %s to device %d, err %d\n", DRIVER_NAME, address, status); -fail1: - kfree(tps); - return 0; + goto fail1; } #ifdef CONFIG_ARM @@ -535,7 +527,7 @@ fail1: tps->irq = OMAP_GPIO_IRQ(58); omap_request_gpio(58); omap_set_gpio_direction(58, 1); - omap_set_gpio_edge_ctrl(58, OMAP_GPIO_FALLING_EDGE); + set_irq_type(tps->irq, IRQT_FALLING); } if (machine_is_omap_osk()) { tps->model = TPS65010; @@ -543,7 +535,7 @@ fail1: tps->irq = OMAP_GPIO_IRQ(OMAP_MPUIO(1)); omap_request_gpio(OMAP_MPUIO(1)); omap_set_gpio_direction(OMAP_MPUIO(1), 1); - omap_set_gpio_edge_ctrl(OMAP_MPUIO(1), OMAP_GPIO_FALLING_EDGE); + set_irq_type(tps->irq, IRQT_FALLING); } if (machine_is_omap_h3()) { tps->model = TPS65013; @@ -633,6 +625,9 @@ fail1: tps->file = debugfs_create_file(DRIVER_NAME, S_IRUGO, NULL, tps, DEBUG_FOPS); return 0; +fail1: + kfree(tps); + return 0; } static int __init tps65010_scan_bus(struct i2c_adapter *bus) @@ -645,7 +640,6 @@ static int __init tps65010_scan_bus(stru static struct i2c_driver tps65010_driver = { .owner = THIS_MODULE, .name = "tps65010", - .id = 888, /* FIXME assign "official" value */ .flags = I2C_DF_NOTIFY, .attach_adapter = tps65010_scan_bus, .detach_client = __exit_p(tps65010_detach_client), @@ -744,7 +738,7 @@ int tps65010_set_led(unsigned led, unsig if (!the_tps) return -ENODEV; - if(led == LED1) + if (led == LED1) offs = 0; else { offs = 2; @@ -753,11 +747,13 @@ int tps65010_set_led(unsigned led, unsig down(&the_tps->lock); - dev_dbg (&the_tps->client.dev, "led%i_on 0x%02x\n", led, - i2c_smbus_read_byte_data(&the_tps->client, TPS_LED1_ON + offs)); - - dev_dbg (&the_tps->client.dev, "led%i_per 0x%02x\n", led, - i2c_smbus_read_byte_data(&the_tps->client, TPS_LED1_PER + offs)); + pr_debug("%s: led%i_on 0x%02x\n", DRIVER_NAME, led, + i2c_smbus_read_byte_data(&the_tps->client, + TPS_LED1_ON + offs)); + + pr_debug("%s: led%i_per 0x%02x\n", DRIVER_NAME, led, + i2c_smbus_read_byte_data(&the_tps->client, + TPS_LED1_PER + offs)); switch (mode) { case OFF: @@ -773,7 +769,7 @@ int tps65010_set_led(unsigned led, unsig led_per = 0x08 | (1 << 7); break; default: - printk(KERN_ERR "%s: Wrong mode parameter for tps65010_set_led()\n", + printk(KERN_ERR "%s: Wrong mode parameter for set_led()\n", DRIVER_NAME); up(&the_tps->lock); return -EINVAL; @@ -789,7 +785,7 @@ int tps65010_set_led(unsigned led, unsig return status; } - dev_dbg (&the_tps->client.dev, "led%i_on 0x%02x\n", led, + pr_debug("%s: led%i_on 0x%02x\n", DRIVER_NAME, led, i2c_smbus_read_byte_data(&the_tps->client, TPS_LED1_ON + offs)); status = i2c_smbus_write_byte_data(&the_tps->client, @@ -802,8 +798,9 @@ int tps65010_set_led(unsigned led, unsig return status; } - dev_dbg (&the_tps->client.dev, "led%i_per 0x%02x\n", led, - i2c_smbus_read_byte_data(&the_tps->client, TPS_LED1_PER + offs)); + pr_debug("%s: led%i_per 0x%02x\n", DRIVER_NAME, led, + i2c_smbus_read_byte_data(&the_tps->client, + TPS_LED1_PER + offs)); up(&the_tps->lock); @@ -874,7 +871,7 @@ int tps65010_set_low_pwr(unsigned mode) if (status != 0) printk(KERN_ERR "%s: Failed to write vdcdc1 register\n", - DRIVER_NAME); + DRIVER_NAME); else pr_debug("%s: vdcdc1 0x%02x\n", DRIVER_NAME, i2c_smbus_read_byte_data(&the_tps->client, TPS_VDCDC1)); @@ -900,14 +897,14 @@ int tps65010_config_vregs1(unsigned valu down(&the_tps->lock); pr_debug("%s: vregs1 0x%02x\n", DRIVER_NAME, - i2c_smbus_read_byte_data(&the_tps->client, TPS_VREGS1)); + i2c_smbus_read_byte_data(&the_tps->client, TPS_VREGS1)); status = i2c_smbus_write_byte_data(&the_tps->client, TPS_VREGS1, value); if (status != 0) printk(KERN_ERR "%s: Failed to write vregs1 register\n", - DRIVER_NAME); + DRIVER_NAME); else pr_debug("%s: vregs1 0x%02x\n", DRIVER_NAME, i2c_smbus_read_byte_data(&the_tps->client, TPS_VREGS1)); @@ -1009,7 +1006,7 @@ static int __init tps_init(void) msleep(10); } -#if defined(CONFIG_ARM) +#ifdef CONFIG_ARM if (machine_is_omap_osk()) { // FIXME: More should be placed in the initialization code ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: minor TPS6501x cleanups @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: david-b [PATCH] I2C: minor TPS6501x cleanups This includes various small cleanups and fixes to the TPS 6501x driver that came mostly from review feedback by Jean Delvare; thanks Jean! Also some goofy whitespace gets fixed. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 65fc50e50ff9f8b82c3756eccd7e7db6a267ffe9 tree b78c1f954841ceb64732ebf355dc070b5ce79094 parent 6328c0e163abfce679b1beffb166f72900bf0a22 author david-b@pacbell.net <david-b@pacbell.net> Wed, 29 Jun 2005 07:13:00 -0700 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/Kconfig | 1 - drivers/i2c/chips/tps65010.c | 61 ++++++++++++++++++++---------------------- 2 files changed, 29 insertions(+), 33 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -509,7 +509,6 @@ config TPS65010 This driver can also be built as a module. If so, the module will be called tps65010. - config SENSORS_M41T00 tristate "ST M41T00 RTC chip" depends on I2C && PPC32 diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c --- a/drivers/i2c/chips/tps65010.c +++ b/drivers/i2c/chips/tps65010.c @@ -18,7 +18,6 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ -#undef DEBUG #include <linux/config.h> #include <linux/kernel.h> @@ -49,11 +48,7 @@ MODULE_DESCRIPTION("TPS6501x Power Management Driver"); MODULE_LICENSE("GPL"); -/* only two addresses possible */ -#define TPS_BASE 0x48 -static unsigned short normal_i2c[] = { - TPS_BASE, - I2C_CLIENT_END }; +static unsigned short normal_i2c[] = { 0x48, /* 0x49, */ I2C_CLIENT_END }; static unsigned short normal_i2c_range[] = { I2C_CLIENT_END }; I2C_CLIENT_INSMOD; @@ -102,7 +97,7 @@ struct tps65010 { u8 chgstatus, regstatus, chgconf; u8 nmask1, nmask2; - /* plus four GPIOs, probably used to switch power */ + /* not currently tracking GPIO state */ }; #define POWER_POLL_DELAY msecs_to_jiffies(800) @@ -135,7 +130,7 @@ static void dbg_regstat(char *buf, size_ (regstatus & TPS_REG_COVER) ? " uncover" : "", (regstatus & TPS_REG_UVLO) ? " UVLO" : "", (regstatus & TPS_REG_NO_CHG) ? " NO_CHG" : "", - (regstatus & TPS_REG_PG_LD02) ? " ld01_bad" : "", + (regstatus & TPS_REG_PG_LD02) ? " ld02_bad" : "", (regstatus & TPS_REG_PG_LD01) ? " ld01_bad" : "", (regstatus & TPS_REG_PG_MAIN) ? " main_bad" : "", (regstatus & TPS_REG_PG_CORE) ? " core_bad" : ""); @@ -143,7 +138,7 @@ static void dbg_regstat(char *buf, size_ static void dbg_chgconf(int por, char *buf, size_t len, u8 chgconfig) { - char *hibit; + const char *hibit; if (por) hibit = (chgconfig & TPS_CHARGE_POR) @@ -295,7 +290,7 @@ static int dbg_show(struct seq_file *s, seq_printf(s, "defgpio %02x mask3 %02x\n", value, v2); for (i = 0; i < 4; i++) { - if (value & (1 << (4 +i))) + if (value & (1 << (4 + i))) seq_printf(s, " gpio%d-out %s\n", i + 1, (value & (1 << i)) ? "low" : "hi "); else @@ -481,7 +476,7 @@ static int __exit tps65010_detach_client debugfs_remove(tps->file); if (i2c_detach_client(client) = 0) kfree(tps); - the_tps = 0; + the_tps = NULL; return 0; } @@ -514,7 +509,6 @@ tps65010_probe(struct i2c_adapter *bus, INIT_WORK(&tps->work, tps65010_work, tps); tps->irq = -1; tps->client.addr = address; - i2c_set_clientdata(&tps->client, tps); tps->client.adapter = bus; tps->client.driver = &tps65010_driver; strlcpy(tps->client.name, DRIVER_NAME, I2C_NAME_SIZE); @@ -523,9 +517,7 @@ tps65010_probe(struct i2c_adapter *bus, if (status < 0) { dev_dbg(&bus->dev, "can't attach %s to device %d, err %d\n", DRIVER_NAME, address, status); -fail1: - kfree(tps); - return 0; + goto fail1; } #ifdef CONFIG_ARM @@ -535,7 +527,7 @@ fail1: tps->irq = OMAP_GPIO_IRQ(58); omap_request_gpio(58); omap_set_gpio_direction(58, 1); - omap_set_gpio_edge_ctrl(58, OMAP_GPIO_FALLING_EDGE); + set_irq_type(tps->irq, IRQT_FALLING); } if (machine_is_omap_osk()) { tps->model = TPS65010; @@ -543,7 +535,7 @@ fail1: tps->irq = OMAP_GPIO_IRQ(OMAP_MPUIO(1)); omap_request_gpio(OMAP_MPUIO(1)); omap_set_gpio_direction(OMAP_MPUIO(1), 1); - omap_set_gpio_edge_ctrl(OMAP_MPUIO(1), OMAP_GPIO_FALLING_EDGE); + set_irq_type(tps->irq, IRQT_FALLING); } if (machine_is_omap_h3()) { tps->model = TPS65013; @@ -633,6 +625,9 @@ fail1: tps->file = debugfs_create_file(DRIVER_NAME, S_IRUGO, NULL, tps, DEBUG_FOPS); return 0; +fail1: + kfree(tps); + return 0; } static int __init tps65010_scan_bus(struct i2c_adapter *bus) @@ -645,7 +640,6 @@ static int __init tps65010_scan_bus(stru static struct i2c_driver tps65010_driver = { .owner = THIS_MODULE, .name = "tps65010", - .id = 888, /* FIXME assign "official" value */ .flags = I2C_DF_NOTIFY, .attach_adapter = tps65010_scan_bus, .detach_client = __exit_p(tps65010_detach_client), @@ -744,7 +738,7 @@ int tps65010_set_led(unsigned led, unsig if (!the_tps) return -ENODEV; - if(led = LED1) + if (led = LED1) offs = 0; else { offs = 2; @@ -753,11 +747,13 @@ int tps65010_set_led(unsigned led, unsig down(&the_tps->lock); - dev_dbg (&the_tps->client.dev, "led%i_on 0x%02x\n", led, - i2c_smbus_read_byte_data(&the_tps->client, TPS_LED1_ON + offs)); - - dev_dbg (&the_tps->client.dev, "led%i_per 0x%02x\n", led, - i2c_smbus_read_byte_data(&the_tps->client, TPS_LED1_PER + offs)); + pr_debug("%s: led%i_on 0x%02x\n", DRIVER_NAME, led, + i2c_smbus_read_byte_data(&the_tps->client, + TPS_LED1_ON + offs)); + + pr_debug("%s: led%i_per 0x%02x\n", DRIVER_NAME, led, + i2c_smbus_read_byte_data(&the_tps->client, + TPS_LED1_PER + offs)); switch (mode) { case OFF: @@ -773,7 +769,7 @@ int tps65010_set_led(unsigned led, unsig led_per = 0x08 | (1 << 7); break; default: - printk(KERN_ERR "%s: Wrong mode parameter for tps65010_set_led()\n", + printk(KERN_ERR "%s: Wrong mode parameter for set_led()\n", DRIVER_NAME); up(&the_tps->lock); return -EINVAL; @@ -789,7 +785,7 @@ int tps65010_set_led(unsigned led, unsig return status; } - dev_dbg (&the_tps->client.dev, "led%i_on 0x%02x\n", led, + pr_debug("%s: led%i_on 0x%02x\n", DRIVER_NAME, led, i2c_smbus_read_byte_data(&the_tps->client, TPS_LED1_ON + offs)); status = i2c_smbus_write_byte_data(&the_tps->client, @@ -802,8 +798,9 @@ int tps65010_set_led(unsigned led, unsig return status; } - dev_dbg (&the_tps->client.dev, "led%i_per 0x%02x\n", led, - i2c_smbus_read_byte_data(&the_tps->client, TPS_LED1_PER + offs)); + pr_debug("%s: led%i_per 0x%02x\n", DRIVER_NAME, led, + i2c_smbus_read_byte_data(&the_tps->client, + TPS_LED1_PER + offs)); up(&the_tps->lock); @@ -874,7 +871,7 @@ int tps65010_set_low_pwr(unsigned mode) if (status != 0) printk(KERN_ERR "%s: Failed to write vdcdc1 register\n", - DRIVER_NAME); + DRIVER_NAME); else pr_debug("%s: vdcdc1 0x%02x\n", DRIVER_NAME, i2c_smbus_read_byte_data(&the_tps->client, TPS_VDCDC1)); @@ -900,14 +897,14 @@ int tps65010_config_vregs1(unsigned valu down(&the_tps->lock); pr_debug("%s: vregs1 0x%02x\n", DRIVER_NAME, - i2c_smbus_read_byte_data(&the_tps->client, TPS_VREGS1)); + i2c_smbus_read_byte_data(&the_tps->client, TPS_VREGS1)); status = i2c_smbus_write_byte_data(&the_tps->client, TPS_VREGS1, value); if (status != 0) printk(KERN_ERR "%s: Failed to write vregs1 register\n", - DRIVER_NAME); + DRIVER_NAME); else pr_debug("%s: vregs1 0x%02x\n", DRIVER_NAME, i2c_smbus_read_byte_data(&the_tps->client, TPS_VREGS1)); @@ -1009,7 +1006,7 @@ static int __init tps_init(void) msleep(10); } -#if defined(CONFIG_ARM) +#ifdef CONFIG_ARM if (machine_is_omap_osk()) { // FIXME: More should be placed in the initialization code ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: New max6875 driver may corrupt EEPROMs 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: New max6875 driver may corrupt EEPROMs After a careful code analysis on the new max6875 driver (drivers/i2c/chips/max6875.c), I have come to the conclusion that this driver may cause EEPROM corruptions if used on random systems. The EEPROM part of the MAX6875 chip is accessed using rather uncommon I2C sequences. What is seen by the MAX6875 as reads can be seen by a standard EEPROM (24C02) as writes. If you check the detection method used by the driver, you'll find that the first SMBus command it will send on the bus is i2c_smbus_write_byte_data(client, 0x80, 0x40). For the MAX6875 it makes an internal pointer point to a specific offset of the EEPROM waiting for a subsequent read command, so it's not an actual data write operation, but for a standard EEPROM, this instead means writing value 0x40 to offset 0x80. Blame Philips and Intel for the obscure protocol. Since the MAX6875 and the standard, common 24C02 EEPROMs share two I2C addresses (0x50 and 0x52), loading the max6875 driver on a system with standard EEPROMs at either address will trigger a write on these EEPROMs, which will lead to their corruption if they happen not to be write protected. This kind of EEPROMs can be found on memory modules (SPD), ethernet adapters (MAC address), laptops (proprietary data) and displays (EDID/DDC). Most of these are hopefully write-protected, but not all of them. For this reason, I would recommend that the max6875 driver be neutralized, in a way that nobody can corrupt his/her EEPROMs by just loading the driver. This means either deleting the driver completely, or not listing any default address for it. I'd like this to be done before 2.6.13-rc1 is released. Additionally, the max6875 driver lacks the 24RF08 corruption preventer present in the eeprom driver, which means that loading this driver in a system with such a chip would corrupt it as well. Here is a proposed quick patch addressing the issue, although I wouldn't mind a complete removal if it makes everyone feel safer. I think Ben has plans to replace this driver by a much simplified one anyway. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 9ab1ee2ab7d65979c0f14a60ee1f29f8988f5811 tree 48ad06b033dfe8a673e026e7a219608b15733199 parent 541e6a02768404efb06bd1ea5f33d614732f41fc author Jean Delvare <khali@linux-fr.org> Fri, 24 Jun 2005 21:14:16 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/max6875.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/chips/max6875.c b/drivers/i2c/chips/max6875.c --- a/drivers/i2c/chips/max6875.c +++ b/drivers/i2c/chips/max6875.c @@ -37,7 +37,8 @@ #include <linux/i2c-sensor.h> /* Addresses to scan */ -static unsigned short normal_i2c[] = {0x50, 0x52, I2C_CLIENT_END}; +/* No address scanned by default, as this could corrupt standard EEPROMS. */ +static unsigned short normal_i2c[] = {I2C_CLIENT_END}; static unsigned int normal_isa[] = {I2C_CLIENT_ISA_END}; /* Insmod parameters */ @@ -369,6 +370,9 @@ static int max6875_detect(struct i2c_ada new_client->driver = &max6875_driver; new_client->flags = 0; + /* Prevent 24RF08 corruption */ + i2c_smbus_write_quick(new_client, 0); + /* Setup the user section */ data->blocks[max6875_eeprom_user].type = max6875_eeprom_user; data->blocks[max6875_eeprom_user].slices = USER_EEPROM_SLICES; ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: New max6875 driver may corrupt EEPROMs @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: New max6875 driver may corrupt EEPROMs After a careful code analysis on the new max6875 driver (drivers/i2c/chips/max6875.c), I have come to the conclusion that this driver may cause EEPROM corruptions if used on random systems. The EEPROM part of the MAX6875 chip is accessed using rather uncommon I2C sequences. What is seen by the MAX6875 as reads can be seen by a standard EEPROM (24C02) as writes. If you check the detection method used by the driver, you'll find that the first SMBus command it will send on the bus is i2c_smbus_write_byte_data(client, 0x80, 0x40). For the MAX6875 it makes an internal pointer point to a specific offset of the EEPROM waiting for a subsequent read command, so it's not an actual data write operation, but for a standard EEPROM, this instead means writing value 0x40 to offset 0x80. Blame Philips and Intel for the obscure protocol. Since the MAX6875 and the standard, common 24C02 EEPROMs share two I2C addresses (0x50 and 0x52), loading the max6875 driver on a system with standard EEPROMs at either address will trigger a write on these EEPROMs, which will lead to their corruption if they happen not to be write protected. This kind of EEPROMs can be found on memory modules (SPD), ethernet adapters (MAC address), laptops (proprietary data) and displays (EDID/DDC). Most of these are hopefully write-protected, but not all of them. For this reason, I would recommend that the max6875 driver be neutralized, in a way that nobody can corrupt his/her EEPROMs by just loading the driver. This means either deleting the driver completely, or not listing any default address for it. I'd like this to be done before 2.6.13-rc1 is released. Additionally, the max6875 driver lacks the 24RF08 corruption preventer present in the eeprom driver, which means that loading this driver in a system with such a chip would corrupt it as well. Here is a proposed quick patch addressing the issue, although I wouldn't mind a complete removal if it makes everyone feel safer. I think Ben has plans to replace this driver by a much simplified one anyway. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 9ab1ee2ab7d65979c0f14a60ee1f29f8988f5811 tree 48ad06b033dfe8a673e026e7a219608b15733199 parent 541e6a02768404efb06bd1ea5f33d614732f41fc author Jean Delvare <khali@linux-fr.org> Fri, 24 Jun 2005 21:14:16 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/chips/max6875.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/chips/max6875.c b/drivers/i2c/chips/max6875.c --- a/drivers/i2c/chips/max6875.c +++ b/drivers/i2c/chips/max6875.c @@ -37,7 +37,8 @@ #include <linux/i2c-sensor.h> /* Addresses to scan */ -static unsigned short normal_i2c[] = {0x50, 0x52, I2C_CLIENT_END}; +/* No address scanned by default, as this could corrupt standard EEPROMS. */ +static unsigned short normal_i2c[] = {I2C_CLIENT_END}; static unsigned int normal_isa[] = {I2C_CLIENT_ISA_END}; /* Insmod parameters */ @@ -369,6 +370,9 @@ static int max6875_detect(struct i2c_ada new_client->driver = &max6875_driver; new_client->flags = 0; + /* Prevent 24RF08 corruption */ + i2c_smbus_write_quick(new_client, 0); + /* Setup the user section */ data->blocks[max6875_eeprom_user].type = max6875_eeprom_user; data->blocks[max6875_eeprom_user].slices = USER_EEPROM_SLICES; ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] i2c: make better use of IDR in i2c-core 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: mhoffman [PATCH] i2c: make better use of IDR in i2c-core This patch uses the already existing IDR mechanism to simplify and improve the i2c_get_adapter function in i2c-core. Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit a0920e10438e9fe8b22aba607083347c84458ed8 tree 8953a2c3c19cab0d4e67fc0e396c23711388403b parent 5da69ba42aa42a479c0f5d8cb8351ebb6b51c12e author Mark M. Hoffman <mhoffman@lightlink.com> Tue, 28 Jun 2005 00:21:30 -0400 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/i2c-core.c | 17 ++++++----------- 1 files changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -156,7 +156,7 @@ int i2c_add_adapter(struct i2c_adapter * goto out_unlock; } - res = idr_get_new(&i2c_adapter_idr, NULL, &id); + res = idr_get_new(&i2c_adapter_idr, adap, &id); if (res < 0) { if (res == -EAGAIN) res = -ENOMEM; @@ -765,20 +765,15 @@ int i2c_adapter_id(struct i2c_adapter *a struct i2c_adapter* i2c_get_adapter(int id) { - struct list_head *item; struct i2c_adapter *adapter; down(&core_lists); - list_for_each(item,&adapters) { - adapter = list_entry(item, struct i2c_adapter, list); - if (id == adapter->nr && - try_module_get(adapter->owner)) { - up(&core_lists); - return adapter; - } - } + adapter = (struct i2c_adapter *)idr_find(&i2c_adapter_idr, id); + if (adapter && !try_module_get(adapter->owner)) + adapter = NULL; + up(&core_lists); - return NULL; + return adapter; } void i2c_put_adapter(struct i2c_adapter *adap) ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] i2c: make better use of IDR in i2c-core @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: mhoffman [PATCH] i2c: make better use of IDR in i2c-core This patch uses the already existing IDR mechanism to simplify and improve the i2c_get_adapter function in i2c-core. Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit a0920e10438e9fe8b22aba607083347c84458ed8 tree 8953a2c3c19cab0d4e67fc0e396c23711388403b parent 5da69ba42aa42a479c0f5d8cb8351ebb6b51c12e author Mark M. Hoffman <mhoffman@lightlink.com> Tue, 28 Jun 2005 00:21:30 -0400 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:36 -0700 drivers/i2c/i2c-core.c | 17 ++++++----------- 1 files changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -156,7 +156,7 @@ int i2c_add_adapter(struct i2c_adapter * goto out_unlock; } - res = idr_get_new(&i2c_adapter_idr, NULL, &id); + res = idr_get_new(&i2c_adapter_idr, adap, &id); if (res < 0) { if (res = -EAGAIN) res = -ENOMEM; @@ -765,20 +765,15 @@ int i2c_adapter_id(struct i2c_adapter *a struct i2c_adapter* i2c_get_adapter(int id) { - struct list_head *item; struct i2c_adapter *adapter; down(&core_lists); - list_for_each(item,&adapters) { - adapter = list_entry(item, struct i2c_adapter, list); - if (id = adapter->nr && - try_module_get(adapter->owner)) { - up(&core_lists); - return adapter; - } - } + adapter = (struct i2c_adapter *)idr_find(&i2c_adapter_idr, id); + if (adapter && !try_module_get(adapter->owner)) + adapter = NULL; + up(&core_lists); - return NULL; + return adapter; } void i2c_put_adapter(struct i2c_adapter *adap) ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] w1: fix CRC calculation on bigendian platforms. 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: johnpol [PATCH] w1: fix CRC calculation on bigendian platforms. In the 2.6.13-rc1 code the "rn" structure is in the wrong-endianness when passed to w1_attach_slave_device(). This causes problems like the family and crc being swapped around. Signed-off-by: Roger Blofeld <blofeldus@yahoo.com> Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 0e65f82814e9828d3ff54988de9e7c0b36794daa tree a4d5dfb9ab550160a453c6266fe67d18ace76857 parent 80efa8c72006a1c04004f8fb07b22073348e4bf2 author Evgeniy Polyakov <johnpol@2ka.mipt.ru> Thu, 30 Jun 2005 22:52:38 +0400 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 drivers/w1/w1.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -516,6 +516,7 @@ static void w1_slave_found(unsigned long struct w1_reg_num *tmp; int family_found = 0; struct w1_master *dev; + u64 rn_le = cpu_to_le64(rn); dev = w1_search_master(data); if (!dev) { @@ -544,10 +545,8 @@ static void w1_slave_found(unsigned long slave_count++; } - rn = cpu_to_le64(rn); - if (slave_count == dev->slave_count && - rn && ((le64_to_cpu(rn) >> 56) & 0xff) == w1_calc_crc8((u8 *)&rn, 7)) { + rn && ((rn >> 56) & 0xff) == w1_calc_crc8((u8 *)&rn_le, 7)) { w1_attach_slave_device(dev, tmp); } ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] w1: fix CRC calculation on bigendian platforms. @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: johnpol [PATCH] w1: fix CRC calculation on bigendian platforms. In the 2.6.13-rc1 code the "rn" structure is in the wrong-endianness when passed to w1_attach_slave_device(). This causes problems like the family and crc being swapped around. Signed-off-by: Roger Blofeld <blofeldus@yahoo.com> Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 0e65f82814e9828d3ff54988de9e7c0b36794daa tree a4d5dfb9ab550160a453c6266fe67d18ace76857 parent 80efa8c72006a1c04004f8fb07b22073348e4bf2 author Evgeniy Polyakov <johnpol@2ka.mipt.ru> Thu, 30 Jun 2005 22:52:38 +0400 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 drivers/w1/w1.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -516,6 +516,7 @@ static void w1_slave_found(unsigned long struct w1_reg_num *tmp; int family_found = 0; struct w1_master *dev; + u64 rn_le = cpu_to_le64(rn); dev = w1_search_master(data); if (!dev) { @@ -544,10 +545,8 @@ static void w1_slave_found(unsigned long slave_count++; } - rn = cpu_to_le64(rn); - if (slave_count = dev->slave_count && - rn && ((le64_to_cpu(rn) >> 56) & 0xff) = w1_calc_crc8((u8 *)&rn, 7)) { + rn && ((rn >> 56) & 0xff) = w1_calc_crc8((u8 *)&rn_le, 7)) { w1_attach_slave_device(dev, tmp); } ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: Clarify the usage of i2c-dev.h 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: Clarify the usage of i2c-dev.h Upon suggestion by Nils Roeder, here is an update to the i2c documentation to clarify which header files user-space applications relying on the i2c-dev interface should include. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 1d772e2587da3c8b0fb8610fcc1c91fd82f87e52 tree 816702c0b2b1a37f772b8884ce2177b88af4ab73 parent a68e2f4895070f3a449bfe5ae1174b73cc900642 author Jean Delvare <khali@linux-fr.org> Sat, 25 Jun 2005 11:37:40 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 Documentation/i2c/dev-interface | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface --- a/Documentation/i2c/dev-interface +++ b/Documentation/i2c/dev-interface @@ -14,9 +14,12 @@ C example ========= So let's say you want to access an i2c adapter from a C program. The -first thing to do is `#include <linux/i2c.h>" and "#include <linux/i2c-dev.h>. -Yes, I know, you should never include kernel header files, but until glibc -knows about i2c, there is not much choice. +first thing to do is "#include <linux/i2c-dev.h>". Please note that +there are two files named "i2c-dev.h" out there, one is distributed +with the Linux kernel and is meant to be included from kernel +driver code, the other one is distributed with lm_sensors and is +meant to be included from user-space programs. You obviously want +the second one here. Now, you have to decide which adapter you want to access. You should inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned @@ -78,7 +81,7 @@ Full interface description ========================== The following IOCTLs are defined and fully supported -(see also i2c-dev.h and i2c.h): +(see also i2c-dev.h): ioctl(file,I2C_SLAVE,long addr) Change slave address. The address is passed in the 7 lower bits of the ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: Clarify the usage of i2c-dev.h @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: Clarify the usage of i2c-dev.h Upon suggestion by Nils Roeder, here is an update to the i2c documentation to clarify which header files user-space applications relying on the i2c-dev interface should include. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 1d772e2587da3c8b0fb8610fcc1c91fd82f87e52 tree 816702c0b2b1a37f772b8884ce2177b88af4ab73 parent a68e2f4895070f3a449bfe5ae1174b73cc900642 author Jean Delvare <khali@linux-fr.org> Sat, 25 Jun 2005 11:37:40 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 Documentation/i2c/dev-interface | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface --- a/Documentation/i2c/dev-interface +++ b/Documentation/i2c/dev-interface @@ -14,9 +14,12 @@ C example ==== So let's say you want to access an i2c adapter from a C program. The -first thing to do is `#include <linux/i2c.h>" and "#include <linux/i2c-dev.h>. -Yes, I know, you should never include kernel header files, but until glibc -knows about i2c, there is not much choice. +first thing to do is "#include <linux/i2c-dev.h>". Please note that +there are two files named "i2c-dev.h" out there, one is distributed +with the Linux kernel and is meant to be included from kernel +driver code, the other one is distributed with lm_sensors and is +meant to be included from user-space programs. You obviously want +the second one here. Now, you have to decide which adapter you want to access. You should inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned @@ -78,7 +81,7 @@ Full interface description ============= The following IOCTLs are defined and fully supported -(see also i2c-dev.h and i2c.h): +(see also i2c-dev.h): ioctl(file,I2C_SLAVE,long addr) Change slave address. The address is passed in the 7 lower bits of the ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: minor I2C doc cleanups 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: david-b [PATCH] I2C: minor I2C doc cleanups The I2C stack has long had "id" fields, of rather dubious utility, in many data structures. This removes mention of one of them from the documentation about how to write an I2C driver, so that only drivers that really need to use them (probably old/legacy code) will have any reason to use this field. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 61f5809d3ebce9d5433b8696048e91405b681023 tree bcb41c29d36b3b6f84d34c7bac05b38855e90742 parent 2db32767874fe53faff4f80de878ca19927efc1f author david-b@pacbell.net <david-b@pacbell.net> Wed, 29 Jun 2005 07:14:06 -0700 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 Documentation/i2c/writing-clients | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -27,7 +27,6 @@ address. static struct i2c_driver foo_driver = { .owner = THIS_MODULE, .name = "Foo version 2.3 driver", - .id = I2C_DRIVERID_FOO, /* from i2c-id.h, optional */ .flags = I2C_DF_NOTIFY, .attach_adapter = &foo_attach_adapter, .detach_client = &foo_detach_client, @@ -37,12 +36,6 @@ static struct i2c_driver foo_driver = { The name can be chosen freely, and may be upto 40 characters long. Please use something descriptive here. -If used, the id should be a unique ID. The range 0xf000 to 0xffff is -reserved for local use, and you can use one of those until you start -distributing the driver, at which time you should contact the i2c authors -to get your own ID(s). Note that most of the time you don't need an ID -at all so you can just omit it. - Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This means that your driver will be notified when new adapters are found. This is almost always what you want. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: minor I2C doc cleanups @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: david-b [PATCH] I2C: minor I2C doc cleanups The I2C stack has long had "id" fields, of rather dubious utility, in many data structures. This removes mention of one of them from the documentation about how to write an I2C driver, so that only drivers that really need to use them (probably old/legacy code) will have any reason to use this field. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 61f5809d3ebce9d5433b8696048e91405b681023 tree bcb41c29d36b3b6f84d34c7bac05b38855e90742 parent 2db32767874fe53faff4f80de878ca19927efc1f author david-b@pacbell.net <david-b@pacbell.net> Wed, 29 Jun 2005 07:14:06 -0700 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 Documentation/i2c/writing-clients | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -27,7 +27,6 @@ address. static struct i2c_driver foo_driver = { .owner = THIS_MODULE, .name = "Foo version 2.3 driver", - .id = I2C_DRIVERID_FOO, /* from i2c-id.h, optional */ .flags = I2C_DF_NOTIFY, .attach_adapter = &foo_attach_adapter, .detach_client = &foo_detach_client, @@ -37,12 +36,6 @@ static struct i2c_driver foo_driver = { The name can be chosen freely, and may be upto 40 characters long. Please use something descriptive here. -If used, the id should be a unique ID. The range 0xf000 to 0xffff is -reserved for local use, and you can use one of those until you start -distributing the driver, at which time you should contact the i2c authors -to get your own ID(s). Note that most of the time you don't need an ID -at all so you can just omit it. - Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This means that your driver will be notified when new adapters are found. This is almost always what you want. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: SENSORS_ATXP1 must select I2C_SENSOR 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: bunk [PATCH] I2C: SENSORS_ATXP1 must select I2C_SENSOR On Thu, Jun 30, 2005 at 11:47:09PM +0200, Sebastian Pigulak wrote: > I've tried patching linux-2.6.13-RC1 with patch-2.6.13-rc1-git2 and > building atxp1(it allows Vcore voltage changing) into the kernel. > Unfortunately, the kernel compilation stops with: > > LD init/built-in.o > LD vmlinux > drivers/built-in.o(.text+0x92298): In function `atxp1_detect': > : undefined reference to `i2c_which_vrm' > drivers/built-in.o(.text+0x921ae): In function `atxp1_attach_adapter': > : undefined reference to `i2c_detect' > make: *** [vmlinux] B??d 1 > ==> ERROR: Build Failed. Aborting... > > Could someone have a look at the module and possibly fix it up? SENSORS_ATXP1 must select I2C_SENSOR. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 80efa8c72006a1c04004f8fb07b22073348e4bf2 tree 48b0d3a256790004ea5383c878f86e05f162ce31 parent 1d772e2587da3c8b0fb8610fcc1c91fd82f87e52 author Adrian Bunk <bunk@stusta.de> Fri, 01 Jul 2005 00:17:27 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 drivers/i2c/chips/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -80,6 +80,7 @@ config SENSORS_ASB100 config SENSORS_ATXP1 tristate "Attansic ATXP1 VID controller" depends on I2C && EXPERIMENTAL + select I2C_SENSOR help If you say yes here you get support for the Attansic ATXP1 VID controller. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: SENSORS_ATXP1 must select I2C_SENSOR @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: bunk [PATCH] I2C: SENSORS_ATXP1 must select I2C_SENSOR On Thu, Jun 30, 2005 at 11:47:09PM +0200, Sebastian Pigulak wrote: > I've tried patching linux-2.6.13-RC1 with patch-2.6.13-rc1-git2 and > building atxp1(it allows Vcore voltage changing) into the kernel. > Unfortunately, the kernel compilation stops with: > > LD init/built-in.o > LD vmlinux > drivers/built-in.o(.text+0x92298): In function `atxp1_detect': > : undefined reference to `i2c_which_vrm' > drivers/built-in.o(.text+0x921ae): In function `atxp1_attach_adapter': > : undefined reference to `i2c_detect' > make: *** [vmlinux] B??d 1 > => ERROR: Build Failed. Aborting... > > Could someone have a look at the module and possibly fix it up? SENSORS_ATXP1 must select I2C_SENSOR. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit 80efa8c72006a1c04004f8fb07b22073348e4bf2 tree 48b0d3a256790004ea5383c878f86e05f162ce31 parent 1d772e2587da3c8b0fb8610fcc1c91fd82f87e52 author Adrian Bunk <bunk@stusta.de> Fri, 01 Jul 2005 00:17:27 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 drivers/i2c/chips/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -80,6 +80,7 @@ config SENSORS_ASB100 config SENSORS_ATXP1 tristate "Attansic ATXP1 VID controller" depends on I2C && EXPERIMENTAL + select I2C_SENSOR help If you say yes here you get support for the Attansic ATXP1 VID controller. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: Documentation fix 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: jan [PATCH] I2C: Documentation fix Fix documentation to match code in include/linux/i2c-dev.h Signed-off-by: Jan Veldeman <jan@mind.be> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit a68e2f4895070f3a449bfe5ae1174b73cc900642 tree 76f3e9e4da1f261687b51aad6c8be3534788e63f parent 61f5809d3ebce9d5433b8696048e91405b681023 author Jan Veldeman <jan@mind.be> Fri, 01 Jul 2005 16:20:24 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 Documentation/i2c/dev-interface | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface --- a/Documentation/i2c/dev-interface +++ b/Documentation/i2c/dev-interface @@ -97,10 +97,10 @@ ioctl(file,I2C_PEC,long select) ioctl(file,I2C_FUNCS,unsigned long *funcs) Gets the adapter functionality and puts it in *funcs. -ioctl(file,I2C_RDWR,struct i2c_ioctl_rdwr_data *msgset) +ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset) Do combined read/write transaction without stop in between. - The argument is a pointer to a struct i2c_ioctl_rdwr_data { + The argument is a pointer to a struct i2c_rdwr_ioctl_data { struct i2c_msg *msgs; /* ptr to array of simple messages */ int nmsgs; /* number of messages to exchange */ ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: Documentation fix @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: jan [PATCH] I2C: Documentation fix Fix documentation to match code in include/linux/i2c-dev.h Signed-off-by: Jan Veldeman <jan@mind.be> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit a68e2f4895070f3a449bfe5ae1174b73cc900642 tree 76f3e9e4da1f261687b51aad6c8be3534788e63f parent 61f5809d3ebce9d5433b8696048e91405b681023 author Jan Veldeman <jan@mind.be> Fri, 01 Jul 2005 16:20:24 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:10:37 -0700 Documentation/i2c/dev-interface | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface --- a/Documentation/i2c/dev-interface +++ b/Documentation/i2c/dev-interface @@ -97,10 +97,10 @@ ioctl(file,I2C_PEC,long select) ioctl(file,I2C_FUNCS,unsigned long *funcs) Gets the adapter functionality and puts it in *funcs. -ioctl(file,I2C_RDWR,struct i2c_ioctl_rdwr_data *msgset) +ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset) Do combined read/write transaction without stop in between. - The argument is a pointer to a struct i2c_ioctl_rdwr_data { + The argument is a pointer to a struct i2c_rdwr_ioctl_data { struct i2c_msg *msgs; /* ptr to array of simple messages */ int nmsgs; /* number of messages to exchange */ ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] I2C: Move hwmon drivers (1/3) 2005-07-12 0:04 ` [lm-sensors] " Greg KH @ 2005-07-12 0:04 ` Greg KH -1 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-11 22:02 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: Move hwmon drivers (1/3) Part 1: Configuration files and Makefiles. From: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit ad2f931dcb41bcfae38cc77d78b7821dfef83cf2 tree 344940f7ce52d94cf9bdd862409c63ebeb9bfa3a parent 0e65f82814e9828d3ff54988de9e7c0b36794daa author Jean Delvare <khali@linux-fr.org> Sat, 02 Jul 2005 18:15:49 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:14:31 -0700 arch/arm/Kconfig | 2 arch/h8300/Kconfig | 2 arch/sparc64/Kconfig | 2 drivers/Kconfig | 2 drivers/Makefile | 1 drivers/hwmon/Kconfig | 420 ++++++++++++++++++++++++++++++++++++++++++++ drivers/hwmon/Makefile | 44 +++++ drivers/i2c/chips/Kconfig | 402 ------------------------------------------ drivers/i2c/chips/Makefile | 38 ---- 9 files changed, 476 insertions(+), 437 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -744,6 +744,8 @@ source "drivers/char/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/hwmon/Kconfig" + #source "drivers/l3/Kconfig" source "drivers/misc/Kconfig" diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -179,6 +179,8 @@ source "drivers/serial/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/hwmon/Kconfig" + source "drivers/usb/Kconfig" endmenu diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig --- a/arch/sparc64/Kconfig +++ b/arch/sparc64/Kconfig @@ -647,6 +647,8 @@ source "drivers/input/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/hwmon/Kconfig" + source "fs/Kconfig" source "drivers/media/Kconfig" diff --git a/drivers/Kconfig b/drivers/Kconfig --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -44,6 +44,8 @@ source "drivers/i2c/Kconfig" source "drivers/w1/Kconfig" +source "drivers/hwmon/Kconfig" + source "drivers/misc/Kconfig" source "drivers/media/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile --- a/drivers/Makefile +++ b/drivers/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_INPUT) += input/ obj-$(CONFIG_I2O) += message/ obj-$(CONFIG_I2C) += i2c/ obj-$(CONFIG_W1) += w1/ +obj-$(CONFIG_HWMON) += hwmon/ obj-$(CONFIG_PHONE) += telephony/ obj-$(CONFIG_MD) += md/ obj-$(CONFIG_BT) += bluetooth/ diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig new file mode 100644 --- /dev/null +++ b/drivers/hwmon/Kconfig @@ -0,0 +1,420 @@ +# +# I2C Sensor chip drivers configuration +# + +menu "Hardware Monitoring support" + +config HWMON + tristate "Hardware Monitoring support" + default y + help + Hardware monitoring devices let you monitor the hardware health + of a system. Most modern motherboards include such a device. It + can include temperature sensors, voltage sensors, fan speed + sensors and various additional features such as the ability to + control the speed of the fans. + +config SENSORS_ADM1021 + tristate "Analog Devices ADM1021 and compatibles" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM1021 + and ADM1023 sensor chips and clones: Maxim MAX1617 and MAX1617A, + Genesys Logic GL523SM, National Semiconductor LM84, TI THMC10, + and the XEON processor built-in sensor. + + This driver can also be built as a module. If so, the module + will be called adm1021. + +config SENSORS_ADM1025 + tristate "Analog Devices ADM1025 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM1025 + and Philips NE1619 sensor chips. + + This driver can also be built as a module. If so, the module + will be called adm1025. + +config SENSORS_ADM1026 + tristate "Analog Devices ADM1026 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM1026 + sensor chip. + + This driver can also be built as a module. If so, the module + will be called adm1026. + +config SENSORS_ADM1031 + tristate "Analog Devices ADM1031 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM1031 + and ADM1030 sensor chips. + + This driver can also be built as a module. If so, the module + will be called adm1031. + +config SENSORS_ADM9240 + tristate "Analog Devices ADM9240 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM9240, + Dallas DS1780, National Semiconductor LM81 sensor chips. + + This driver can also be built as a module. If so, the module + will be called adm9240. + +config SENSORS_ASB100 + tristate "Asus ASB100 Bach" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for the ASB100 Bach sensor + chip found on some Asus mainboards. + + This driver can also be built as a module. If so, the module + will be called asb100. + +config SENSORS_ATXP1 + tristate "Attansic ATXP1 VID controller" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for the Attansic ATXP1 VID + controller. + + If your board have such a chip, you are able to control your CPU + core and other voltages. + + This driver can also be built as a module. If so, the module + will be called atxp1. + +config SENSORS_DS1621 + tristate "Dallas Semiconductor DS1621 and DS1625" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Dallas Semiconductor + DS1621 and DS1625 sensor chips. + + This driver can also be built as a module. If so, the module + will be called ds1621. + +config SENSORS_FSCHER + tristate "FSC Hermes" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Fujitsu Siemens + Computers Hermes sensor chips. + + This driver can also be built as a module. If so, the module + will be called fscher. + +config SENSORS_FSCPOS + tristate "FSC Poseidon" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Fujitsu Siemens + Computers Poseidon sensor chips. + + This driver can also be built as a module. If so, the module + will be called fscpos. + +config SENSORS_GL518SM + tristate "Genesys Logic GL518SM" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for Genesys Logic GL518SM + sensor chips. + + This driver can also be built as a module. If so, the module + will be called gl518sm. + +config SENSORS_GL520SM + tristate "Genesys Logic GL520SM" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Genesys Logic GL520SM + sensor chips. + + This driver can also be built as a module. If so, the module + will be called gl520sm. + +config SENSORS_IT87 + tristate "ITE IT87xx and compatibles" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for ITE IT87xx sensor chips + and clones: SiS960. + + This driver can also be built as a module. If so, the module + will be called it87. + +config SENSORS_LM63 + tristate "National Semiconductor LM63" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for the National Semiconductor + LM63 remote diode digital temperature sensor with integrated fan + control. Such chips are found on the Tyan S4882 (Thunder K8QS Pro) + motherboard, among others. + + This driver can also be built as a module. If so, the module + will be called lm63. + +config SENSORS_LM75 + tristate "National Semiconductor LM75 and compatibles" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM75 + sensor chips and clones: Dallas Semiconductor DS75 and DS1775 (in + 9-bit precision mode), and TelCom (now Microchip) TCN75. + + The DS75 and DS1775 in 10- to 12-bit precision modes will require + a force module parameter. The driver will not handle the extra + precision anyhow. + + This driver can also be built as a module. If so, the module + will be called lm75. + +config SENSORS_LM77 + tristate "National Semiconductor LM77" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM77 + sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm77. + +config SENSORS_LM78 + tristate "National Semiconductor LM78 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM78, + LM78-J and LM79. + + This driver can also be built as a module. If so, the module + will be called lm78. + +config SENSORS_LM80 + tristate "National Semiconductor LM80" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor + LM80 sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm80. + +config SENSORS_LM83 + tristate "National Semiconductor LM83" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor + LM83 sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm83. + +config SENSORS_LM85 + tristate "National Semiconductor LM85 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM85 + sensor chips and clones: ADT7463, EMC6D100, EMC6D102 and ADM1027. + + This driver can also be built as a module. If so, the module + will be called lm85. + +config SENSORS_LM87 + tristate "National Semiconductor LM87" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM87 + sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm87. + +config SENSORS_LM90 + tristate "National Semiconductor LM90 and compatibles" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM90, + LM86, LM89 and LM99, Analog Devices ADM1032 and Maxim MAX6657 and + MAX6658 sensor chips. + + The Analog Devices ADT7461 sensor chip is also supported, but only + if found in ADM1032 compatibility mode. + + This driver can also be built as a module. If so, the module + will be called lm90. + +config SENSORS_LM92 + tristate "National Semiconductor LM92 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM92 + and Maxim MAX6635 sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm92. + +config SENSORS_MAX1619 + tristate "Maxim MAX1619 sensor chip" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for MAX1619 sensor chip. + + This driver can also be built as a module. If so, the module + will be called max1619. + +config SENSORS_PC87360 + tristate "National Semiconductor PC87360 family" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get access to the hardware monitoring + functions of the National Semiconductor PC8736x Super-I/O chips. + The PC87360, PC87363 and PC87364 only have fan monitoring and + control. The PC87365 and PC87366 additionally have voltage and + temperature monitoring. + + This driver can also be built as a module. If so, the module + will be called pc87360. + +config SENSORS_SIS5595 + tristate "Silicon Integrated Systems Corp. SiS5595" + depends on HWMON && I2C && PCI && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the integrated sensors in + SiS5595 South Bridges. + + This driver can also be built as a module. If so, the module + will be called sis5595. + +config SENSORS_SMSC47M1 + tristate "SMSC LPC47M10x and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the integrated fan + monitoring and control capabilities of the SMSC LPC47B27x, + LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192 chips. + + This driver can also be built as a module. If so, the module + will be called smsc47m1. + +config SENSORS_SMSC47B397 + tristate "SMSC LPC47B397-NC" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the SMSC LPC47B397-NC + sensor chip. + + This driver can also be built as a module. If so, the module + will be called smsc47b397. + +config SENSORS_VIA686A + tristate "VIA686A" + depends on HWMON && I2C && PCI + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the integrated sensors in + Via 686A/B South Bridges. + + This driver can also be built as a module. If so, the module + will be called via686a. + +config SENSORS_W83781D + tristate "Winbond W83781D, W83782D, W83783S, W83627HF, Asus AS99127F" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for the Winbond W8378x series + of sensor chips: the W83781D, W83782D, W83783S and W83627HF, + and the similar Asus AS99127F. + + This driver can also be built as a module. If so, the module + will be called w83781d. + +config SENSORS_W83L785TS + tristate "Winbond W83L785TS-S" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for the Winbond W83L785TS-S + sensor chip, which is used on the Asus A7N8X, among other + motherboards. + + This driver can also be built as a module. If so, the module + will be called w83l785ts. + +config SENSORS_W83627HF + tristate "Winbond W83627HF, W83627THF, W83637HF, W83697HF" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the Winbond W836X7 series + of sensor chips: the W83627HF, W83627THF, W83637HF, and the W83697HF + + This driver can also be built as a module. If so, the module + will be called w83627hf. + +config SENSORS_W83627EHF + tristate "Winbond W83627EHF" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get preliminary support for the hardware + monitoring functionality of the Winbond W83627EHF Super-I/O chip. + Only fan and temperature inputs are supported at the moment, while + the chip does much more than that. + + This driver can also be built as a module. If so, the module + will be called w83627ehf. + +config HWMON_DEBUG_CHIP + bool "Hardware Monitoring Chip debugging messages" + depends on HWMON + default n + help + Say Y here if you want the I2C chip drivers to produce a bunch of + debug messages to the system log. Select this if you are having + a problem with I2C support and want to see more of what is going + on. + +endmenu diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile new file mode 100644 --- /dev/null +++ b/drivers/hwmon/Makefile @@ -0,0 +1,44 @@ +# +# Makefile for sensor chip drivers. +# + +# asb100, then w83781d go first, as they can override other drivers' addresses. +obj-$(CONFIG_SENSORS_ASB100) += asb100.o +obj-$(CONFIG_SENSORS_W83627HF) += w83627hf.o +obj-$(CONFIG_SENSORS_W83781D) += w83781d.o + +obj-$(CONFIG_SENSORS_ADM1021) += adm1021.o +obj-$(CONFIG_SENSORS_ADM1025) += adm1025.o +obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o +obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o +obj-$(CONFIG_SENSORS_ADM9240) += adm9240.o +obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o +obj-$(CONFIG_SENSORS_DS1621) += ds1621.o +obj-$(CONFIG_SENSORS_FSCHER) += fscher.o +obj-$(CONFIG_SENSORS_FSCPOS) += fscpos.o +obj-$(CONFIG_SENSORS_GL518SM) += gl518sm.o +obj-$(CONFIG_SENSORS_GL520SM) += gl520sm.o +obj-$(CONFIG_SENSORS_IT87) += it87.o +obj-$(CONFIG_SENSORS_LM63) += lm63.o +obj-$(CONFIG_SENSORS_LM75) += lm75.o +obj-$(CONFIG_SENSORS_LM77) += lm77.o +obj-$(CONFIG_SENSORS_LM78) += lm78.o +obj-$(CONFIG_SENSORS_LM80) += lm80.o +obj-$(CONFIG_SENSORS_LM83) += lm83.o +obj-$(CONFIG_SENSORS_LM85) += lm85.o +obj-$(CONFIG_SENSORS_LM87) += lm87.o +obj-$(CONFIG_SENSORS_LM90) += lm90.o +obj-$(CONFIG_SENSORS_LM92) += lm92.o +obj-$(CONFIG_SENSORS_MAX1619) += max1619.o +obj-$(CONFIG_SENSORS_PC87360) += pc87360.o +obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o +obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o +obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o +obj-$(CONFIG_SENSORS_VIA686A) += via686a.o +obj-$(CONFIG_SENSORS_W83627EHF) += w83627ehf.o +obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o + +ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y) +EXTRA_CFLAGS += -DDEBUG +endif + diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -1,410 +1,12 @@ # -# I2C Sensor and "other" chip configuration +# Miscellaneous I2C chip drivers configuration # -menu "Hardware Sensors Chip support" - depends on I2C - config I2C_SENSOR tristate default n -config SENSORS_ADM1021 - tristate "Analog Devices ADM1021 and compatibles" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM1021 - and ADM1023 sensor chips and clones: Maxim MAX1617 and MAX1617A, - Genesys Logic GL523SM, National Semiconductor LM84, TI THMC10, - and the XEON processor built-in sensor. - - This driver can also be built as a module. If so, the module - will be called adm1021. - -config SENSORS_ADM1025 - tristate "Analog Devices ADM1025 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM1025 - and Philips NE1619 sensor chips. - - This driver can also be built as a module. If so, the module - will be called adm1025. - -config SENSORS_ADM1026 - tristate "Analog Devices ADM1026 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM1026 - sensor chip. - - This driver can also be built as a module. If so, the module - will be called adm1026. - -config SENSORS_ADM1031 - tristate "Analog Devices ADM1031 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM1031 - and ADM1030 sensor chips. - - This driver can also be built as a module. If so, the module - will be called adm1031. - -config SENSORS_ADM9240 - tristate "Analog Devices ADM9240 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM9240, - Dallas DS1780, National Semiconductor LM81 sensor chips. - - This driver can also be built as a module. If so, the module - will be called adm9240. - -config SENSORS_ASB100 - tristate "Asus ASB100 Bach" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for the ASB100 Bach sensor - chip found on some Asus mainboards. - - This driver can also be built as a module. If so, the module - will be called asb100. - -config SENSORS_ATXP1 - tristate "Attansic ATXP1 VID controller" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for the Attansic ATXP1 VID - controller. - - If your board have such a chip, you are able to control your CPU - core and other voltages. - - This driver can also be built as a module. If so, the module - will be called atxp1. - -config SENSORS_DS1621 - tristate "Dallas Semiconductor DS1621 and DS1625" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Dallas Semiconductor - DS1621 and DS1625 sensor chips. - - This driver can also be built as a module. If so, the module - will be called ds1621. - -config SENSORS_FSCHER - tristate "FSC Hermes" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Fujitsu Siemens - Computers Hermes sensor chips. - - This driver can also be built as a module. If so, the module - will be called fscher. - -config SENSORS_FSCPOS - tristate "FSC Poseidon" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Fujitsu Siemens - Computers Poseidon sensor chips. - - This driver can also be built as a module. If so, the module - will be called fscpos. - -config SENSORS_GL518SM - tristate "Genesys Logic GL518SM" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for Genesys Logic GL518SM - sensor chips. - - This driver can also be built as a module. If so, the module - will be called gl518sm. - -config SENSORS_GL520SM - tristate "Genesys Logic GL520SM" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Genesys Logic GL520SM - sensor chips. - - This driver can also be built as a module. If so, the module - will be called gl520sm. - -config SENSORS_IT87 - tristate "ITE IT87xx and compatibles" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for ITE IT87xx sensor chips - and clones: SiS960. - - This driver can also be built as a module. If so, the module - will be called it87. - -config SENSORS_LM63 - tristate "National Semiconductor LM63" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for the National Semiconductor - LM63 remote diode digital temperature sensor with integrated fan - control. Such chips are found on the Tyan S4882 (Thunder K8QS Pro) - motherboard, among others. - - This driver can also be built as a module. If so, the module - will be called lm63. - -config SENSORS_LM75 - tristate "National Semiconductor LM75 and compatibles" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM75 - sensor chips and clones: Dallas Semiconductor DS75 and DS1775 (in - 9-bit precision mode), and TelCom (now Microchip) TCN75. - - The DS75 and DS1775 in 10- to 12-bit precision modes will require - a force module parameter. The driver will not handle the extra - precision anyhow. - - This driver can also be built as a module. If so, the module - will be called lm75. - -config SENSORS_LM77 - tristate "National Semiconductor LM77" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM77 - sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm77. - -config SENSORS_LM78 - tristate "National Semiconductor LM78 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM78, - LM78-J and LM79. - - This driver can also be built as a module. If so, the module - will be called lm78. - -config SENSORS_LM80 - tristate "National Semiconductor LM80" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor - LM80 sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm80. - -config SENSORS_LM83 - tristate "National Semiconductor LM83" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor - LM83 sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm83. - -config SENSORS_LM85 - tristate "National Semiconductor LM85 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM85 - sensor chips and clones: ADT7463, EMC6D100, EMC6D102 and ADM1027. - - This driver can also be built as a module. If so, the module - will be called lm85. - -config SENSORS_LM87 - tristate "National Semiconductor LM87" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM87 - sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm87. - -config SENSORS_LM90 - tristate "National Semiconductor LM90 and compatibles" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM90, - LM86, LM89 and LM99, Analog Devices ADM1032 and Maxim MAX6657 and - MAX6658 sensor chips. - - The Analog Devices ADT7461 sensor chip is also supported, but only - if found in ADM1032 compatibility mode. - - This driver can also be built as a module. If so, the module - will be called lm90. - -config SENSORS_LM92 - tristate "National Semiconductor LM92 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM92 - and Maxim MAX6635 sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm92. - -config SENSORS_MAX1619 - tristate "Maxim MAX1619 sensor chip" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for MAX1619 sensor chip. - - This driver can also be built as a module. If so, the module - will be called max1619. - -config SENSORS_PC87360 - tristate "National Semiconductor PC87360 family" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get access to the hardware monitoring - functions of the National Semiconductor PC8736x Super-I/O chips. - The PC87360, PC87363 and PC87364 only have fan monitoring and - control. The PC87365 and PC87366 additionally have voltage and - temperature monitoring. - - This driver can also be built as a module. If so, the module - will be called pc87360. - -config SENSORS_SMSC47B397 - tristate "SMSC LPC47B397-NC" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the SMSC LPC47B397-NC - sensor chip. - - This driver can also be built as a module. If so, the module - will be called smsc47b397. - -config SENSORS_SIS5595 - tristate "Silicon Integrated Systems Corp. SiS5595" - depends on I2C && PCI && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the integrated sensors in - SiS5595 South Bridges. - - This driver can also be built as a module. If so, the module - will be called sis5595. - -config SENSORS_SMSC47M1 - tristate "SMSC LPC47M10x and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the integrated fan - monitoring and control capabilities of the SMSC LPC47B27x, - LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192 chips. - - This driver can also be built as a module. If so, the module - will be called smsc47m1. - -config SENSORS_VIA686A - tristate "VIA686A" - depends on I2C && PCI - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the integrated sensors in - Via 686A/B South Bridges. - - This driver can also be built as a module. If so, the module - will be called via686a. - -config SENSORS_W83781D - tristate "Winbond W83781D, W83782D, W83783S, W83627HF, Asus AS99127F" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for the Winbond W8378x series - of sensor chips: the W83781D, W83782D, W83783S and W83627HF, - and the similar Asus AS99127F. - - This driver can also be built as a module. If so, the module - will be called w83781d. - -config SENSORS_W83L785TS - tristate "Winbond W83L785TS-S" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for the Winbond W83L785TS-S - sensor chip, which is used on the Asus A7N8X, among other - motherboards. - - This driver can also be built as a module. If so, the module - will be called w83l785ts. - -config SENSORS_W83627HF - tristate "Winbond W83627HF, W83627THF, W83637HF, W83697HF" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the Winbond W836X7 series - of sensor chips: the W83627HF, W83627THF, W83637HF, and the W83697HF - - This driver can also be built as a module. If so, the module - will be called w83627hf. - -config SENSORS_W83627EHF - tristate "Winbond W83627EHF" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get preliminary support for the hardware - monitoring functionality of the Winbond W83627EHF Super-I/O chip. - Only fan and temperature inputs are supported at the moment, while - the chip does much more than that. - - This driver can also be built as a module. If so, the module - will be called w83627ehf. - -endmenu - -menu "Other I2C Chip support" +menu "Miscellaneous I2C Chip support" depends on I2C config SENSORS_DS1337 diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile --- a/drivers/i2c/chips/Makefile +++ b/drivers/i2c/chips/Makefile @@ -1,52 +1,16 @@ # -# Makefile for sensor and "other" I2C chip drivers. +# Makefile for miscellaneous I2C chip drivers. # -# asb100, then w83781d go first, as they can override other drivers' addresses. -obj-$(CONFIG_SENSORS_ASB100) += asb100.o -obj-$(CONFIG_SENSORS_W83627HF) += w83627hf.o -obj-$(CONFIG_SENSORS_W83781D) += w83781d.o - -obj-$(CONFIG_SENSORS_ADM1021) += adm1021.o -obj-$(CONFIG_SENSORS_ADM1025) += adm1025.o -obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o -obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o -obj-$(CONFIG_SENSORS_ADM9240) += adm9240.o -obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o obj-$(CONFIG_SENSORS_DS1337) += ds1337.o obj-$(CONFIG_SENSORS_DS1374) += ds1374.o -obj-$(CONFIG_SENSORS_DS1621) += ds1621.o obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o -obj-$(CONFIG_SENSORS_FSCHER) += fscher.o -obj-$(CONFIG_SENSORS_FSCPOS) += fscpos.o -obj-$(CONFIG_SENSORS_GL518SM) += gl518sm.o -obj-$(CONFIG_SENSORS_GL520SM) += gl520sm.o -obj-$(CONFIG_SENSORS_IT87) += it87.o -obj-$(CONFIG_SENSORS_LM63) += lm63.o -obj-$(CONFIG_SENSORS_LM75) += lm75.o -obj-$(CONFIG_SENSORS_LM77) += lm77.o -obj-$(CONFIG_SENSORS_LM78) += lm78.o -obj-$(CONFIG_SENSORS_LM80) += lm80.o -obj-$(CONFIG_SENSORS_LM83) += lm83.o -obj-$(CONFIG_SENSORS_LM85) += lm85.o -obj-$(CONFIG_SENSORS_LM87) += lm87.o -obj-$(CONFIG_SENSORS_LM90) += lm90.o -obj-$(CONFIG_SENSORS_LM92) += lm92.o -obj-$(CONFIG_SENSORS_MAX1619) += max1619.o obj-$(CONFIG_SENSORS_MAX6875) += max6875.o obj-$(CONFIG_SENSORS_M41T00) += m41t00.o -obj-$(CONFIG_SENSORS_PC87360) += pc87360.o obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o obj-$(CONFIG_SENSORS_RTC8564) += rtc8564.o -obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o -obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o -obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o -obj-$(CONFIG_SENSORS_VIA686A) += via686a.o -obj-$(CONFIG_SENSORS_W83627EHF) += w83627ehf.o -obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o - obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o obj-$(CONFIG_TPS65010) += tps65010.o ^ permalink raw reply [flat|nested] 32+ messages in thread
* [lm-sensors] [PATCH] I2C: Move hwmon drivers (1/3) @ 2005-07-12 0:04 ` Greg KH 0 siblings, 0 replies; 32+ messages in thread From: Greg KH @ 2005-07-12 0:04 UTC (permalink / raw) To: linux-kernel, lm-sensors; +Cc: khali [PATCH] I2C: Move hwmon drivers (1/3) Part 1: Configuration files and Makefiles. From: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- commit ad2f931dcb41bcfae38cc77d78b7821dfef83cf2 tree 344940f7ce52d94cf9bdd862409c63ebeb9bfa3a parent 0e65f82814e9828d3ff54988de9e7c0b36794daa author Jean Delvare <khali@linux-fr.org> Sat, 02 Jul 2005 18:15:49 +0200 committer Greg Kroah-Hartman <gregkh@suse.de> Mon, 11 Jul 2005 14:14:31 -0700 arch/arm/Kconfig | 2 arch/h8300/Kconfig | 2 arch/sparc64/Kconfig | 2 drivers/Kconfig | 2 drivers/Makefile | 1 drivers/hwmon/Kconfig | 420 ++++++++++++++++++++++++++++++++++++++++++++ drivers/hwmon/Makefile | 44 +++++ drivers/i2c/chips/Kconfig | 402 ------------------------------------------ drivers/i2c/chips/Makefile | 38 ---- 9 files changed, 476 insertions(+), 437 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -744,6 +744,8 @@ source "drivers/char/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/hwmon/Kconfig" + #source "drivers/l3/Kconfig" source "drivers/misc/Kconfig" diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -179,6 +179,8 @@ source "drivers/serial/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/hwmon/Kconfig" + source "drivers/usb/Kconfig" endmenu diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig --- a/arch/sparc64/Kconfig +++ b/arch/sparc64/Kconfig @@ -647,6 +647,8 @@ source "drivers/input/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/hwmon/Kconfig" + source "fs/Kconfig" source "drivers/media/Kconfig" diff --git a/drivers/Kconfig b/drivers/Kconfig --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -44,6 +44,8 @@ source "drivers/i2c/Kconfig" source "drivers/w1/Kconfig" +source "drivers/hwmon/Kconfig" + source "drivers/misc/Kconfig" source "drivers/media/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile --- a/drivers/Makefile +++ b/drivers/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_INPUT) += input/ obj-$(CONFIG_I2O) += message/ obj-$(CONFIG_I2C) += i2c/ obj-$(CONFIG_W1) += w1/ +obj-$(CONFIG_HWMON) += hwmon/ obj-$(CONFIG_PHONE) += telephony/ obj-$(CONFIG_MD) += md/ obj-$(CONFIG_BT) += bluetooth/ diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig new file mode 100644 --- /dev/null +++ b/drivers/hwmon/Kconfig @@ -0,0 +1,420 @@ +# +# I2C Sensor chip drivers configuration +# + +menu "Hardware Monitoring support" + +config HWMON + tristate "Hardware Monitoring support" + default y + help + Hardware monitoring devices let you monitor the hardware health + of a system. Most modern motherboards include such a device. It + can include temperature sensors, voltage sensors, fan speed + sensors and various additional features such as the ability to + control the speed of the fans. + +config SENSORS_ADM1021 + tristate "Analog Devices ADM1021 and compatibles" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM1021 + and ADM1023 sensor chips and clones: Maxim MAX1617 and MAX1617A, + Genesys Logic GL523SM, National Semiconductor LM84, TI THMC10, + and the XEON processor built-in sensor. + + This driver can also be built as a module. If so, the module + will be called adm1021. + +config SENSORS_ADM1025 + tristate "Analog Devices ADM1025 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM1025 + and Philips NE1619 sensor chips. + + This driver can also be built as a module. If so, the module + will be called adm1025. + +config SENSORS_ADM1026 + tristate "Analog Devices ADM1026 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM1026 + sensor chip. + + This driver can also be built as a module. If so, the module + will be called adm1026. + +config SENSORS_ADM1031 + tristate "Analog Devices ADM1031 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM1031 + and ADM1030 sensor chips. + + This driver can also be built as a module. If so, the module + will be called adm1031. + +config SENSORS_ADM9240 + tristate "Analog Devices ADM9240 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Analog Devices ADM9240, + Dallas DS1780, National Semiconductor LM81 sensor chips. + + This driver can also be built as a module. If so, the module + will be called adm9240. + +config SENSORS_ASB100 + tristate "Asus ASB100 Bach" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for the ASB100 Bach sensor + chip found on some Asus mainboards. + + This driver can also be built as a module. If so, the module + will be called asb100. + +config SENSORS_ATXP1 + tristate "Attansic ATXP1 VID controller" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for the Attansic ATXP1 VID + controller. + + If your board have such a chip, you are able to control your CPU + core and other voltages. + + This driver can also be built as a module. If so, the module + will be called atxp1. + +config SENSORS_DS1621 + tristate "Dallas Semiconductor DS1621 and DS1625" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Dallas Semiconductor + DS1621 and DS1625 sensor chips. + + This driver can also be built as a module. If so, the module + will be called ds1621. + +config SENSORS_FSCHER + tristate "FSC Hermes" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Fujitsu Siemens + Computers Hermes sensor chips. + + This driver can also be built as a module. If so, the module + will be called fscher. + +config SENSORS_FSCPOS + tristate "FSC Poseidon" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Fujitsu Siemens + Computers Poseidon sensor chips. + + This driver can also be built as a module. If so, the module + will be called fscpos. + +config SENSORS_GL518SM + tristate "Genesys Logic GL518SM" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for Genesys Logic GL518SM + sensor chips. + + This driver can also be built as a module. If so, the module + will be called gl518sm. + +config SENSORS_GL520SM + tristate "Genesys Logic GL520SM" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for Genesys Logic GL520SM + sensor chips. + + This driver can also be built as a module. If so, the module + will be called gl520sm. + +config SENSORS_IT87 + tristate "ITE IT87xx and compatibles" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for ITE IT87xx sensor chips + and clones: SiS960. + + This driver can also be built as a module. If so, the module + will be called it87. + +config SENSORS_LM63 + tristate "National Semiconductor LM63" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for the National Semiconductor + LM63 remote diode digital temperature sensor with integrated fan + control. Such chips are found on the Tyan S4882 (Thunder K8QS Pro) + motherboard, among others. + + This driver can also be built as a module. If so, the module + will be called lm63. + +config SENSORS_LM75 + tristate "National Semiconductor LM75 and compatibles" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM75 + sensor chips and clones: Dallas Semiconductor DS75 and DS1775 (in + 9-bit precision mode), and TelCom (now Microchip) TCN75. + + The DS75 and DS1775 in 10- to 12-bit precision modes will require + a force module parameter. The driver will not handle the extra + precision anyhow. + + This driver can also be built as a module. If so, the module + will be called lm75. + +config SENSORS_LM77 + tristate "National Semiconductor LM77" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM77 + sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm77. + +config SENSORS_LM78 + tristate "National Semiconductor LM78 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM78, + LM78-J and LM79. + + This driver can also be built as a module. If so, the module + will be called lm78. + +config SENSORS_LM80 + tristate "National Semiconductor LM80" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor + LM80 sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm80. + +config SENSORS_LM83 + tristate "National Semiconductor LM83" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor + LM83 sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm83. + +config SENSORS_LM85 + tristate "National Semiconductor LM85 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM85 + sensor chips and clones: ADT7463, EMC6D100, EMC6D102 and ADM1027. + + This driver can also be built as a module. If so, the module + will be called lm85. + +config SENSORS_LM87 + tristate "National Semiconductor LM87" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM87 + sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm87. + +config SENSORS_LM90 + tristate "National Semiconductor LM90 and compatibles" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM90, + LM86, LM89 and LM99, Analog Devices ADM1032 and Maxim MAX6657 and + MAX6658 sensor chips. + + The Analog Devices ADT7461 sensor chip is also supported, but only + if found in ADM1032 compatibility mode. + + This driver can also be built as a module. If so, the module + will be called lm90. + +config SENSORS_LM92 + tristate "National Semiconductor LM92 and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for National Semiconductor LM92 + and Maxim MAX6635 sensor chips. + + This driver can also be built as a module. If so, the module + will be called lm92. + +config SENSORS_MAX1619 + tristate "Maxim MAX1619 sensor chip" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for MAX1619 sensor chip. + + This driver can also be built as a module. If so, the module + will be called max1619. + +config SENSORS_PC87360 + tristate "National Semiconductor PC87360 family" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get access to the hardware monitoring + functions of the National Semiconductor PC8736x Super-I/O chips. + The PC87360, PC87363 and PC87364 only have fan monitoring and + control. The PC87365 and PC87366 additionally have voltage and + temperature monitoring. + + This driver can also be built as a module. If so, the module + will be called pc87360. + +config SENSORS_SIS5595 + tristate "Silicon Integrated Systems Corp. SiS5595" + depends on HWMON && I2C && PCI && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the integrated sensors in + SiS5595 South Bridges. + + This driver can also be built as a module. If so, the module + will be called sis5595. + +config SENSORS_SMSC47M1 + tristate "SMSC LPC47M10x and compatibles" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the integrated fan + monitoring and control capabilities of the SMSC LPC47B27x, + LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192 chips. + + This driver can also be built as a module. If so, the module + will be called smsc47m1. + +config SENSORS_SMSC47B397 + tristate "SMSC LPC47B397-NC" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the SMSC LPC47B397-NC + sensor chip. + + This driver can also be built as a module. If so, the module + will be called smsc47b397. + +config SENSORS_VIA686A + tristate "VIA686A" + depends on HWMON && I2C && PCI + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the integrated sensors in + Via 686A/B South Bridges. + + This driver can also be built as a module. If so, the module + will be called via686a. + +config SENSORS_W83781D + tristate "Winbond W83781D, W83782D, W83783S, W83627HF, Asus AS99127F" + depends on HWMON && I2C + select I2C_SENSOR + help + If you say yes here you get support for the Winbond W8378x series + of sensor chips: the W83781D, W83782D, W83783S and W83627HF, + and the similar Asus AS99127F. + + This driver can also be built as a module. If so, the module + will be called w83781d. + +config SENSORS_W83L785TS + tristate "Winbond W83L785TS-S" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get support for the Winbond W83L785TS-S + sensor chip, which is used on the Asus A7N8X, among other + motherboards. + + This driver can also be built as a module. If so, the module + will be called w83l785ts. + +config SENSORS_W83627HF + tristate "Winbond W83627HF, W83627THF, W83637HF, W83697HF" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get support for the Winbond W836X7 series + of sensor chips: the W83627HF, W83627THF, W83637HF, and the W83697HF + + This driver can also be built as a module. If so, the module + will be called w83627hf. + +config SENSORS_W83627EHF + tristate "Winbond W83627EHF" + depends on HWMON && I2C && EXPERIMENTAL + select I2C_SENSOR + select I2C_ISA + help + If you say yes here you get preliminary support for the hardware + monitoring functionality of the Winbond W83627EHF Super-I/O chip. + Only fan and temperature inputs are supported at the moment, while + the chip does much more than that. + + This driver can also be built as a module. If so, the module + will be called w83627ehf. + +config HWMON_DEBUG_CHIP + bool "Hardware Monitoring Chip debugging messages" + depends on HWMON + default n + help + Say Y here if you want the I2C chip drivers to produce a bunch of + debug messages to the system log. Select this if you are having + a problem with I2C support and want to see more of what is going + on. + +endmenu diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile new file mode 100644 --- /dev/null +++ b/drivers/hwmon/Makefile @@ -0,0 +1,44 @@ +# +# Makefile for sensor chip drivers. +# + +# asb100, then w83781d go first, as they can override other drivers' addresses. +obj-$(CONFIG_SENSORS_ASB100) += asb100.o +obj-$(CONFIG_SENSORS_W83627HF) += w83627hf.o +obj-$(CONFIG_SENSORS_W83781D) += w83781d.o + +obj-$(CONFIG_SENSORS_ADM1021) += adm1021.o +obj-$(CONFIG_SENSORS_ADM1025) += adm1025.o +obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o +obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o +obj-$(CONFIG_SENSORS_ADM9240) += adm9240.o +obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o +obj-$(CONFIG_SENSORS_DS1621) += ds1621.o +obj-$(CONFIG_SENSORS_FSCHER) += fscher.o +obj-$(CONFIG_SENSORS_FSCPOS) += fscpos.o +obj-$(CONFIG_SENSORS_GL518SM) += gl518sm.o +obj-$(CONFIG_SENSORS_GL520SM) += gl520sm.o +obj-$(CONFIG_SENSORS_IT87) += it87.o +obj-$(CONFIG_SENSORS_LM63) += lm63.o +obj-$(CONFIG_SENSORS_LM75) += lm75.o +obj-$(CONFIG_SENSORS_LM77) += lm77.o +obj-$(CONFIG_SENSORS_LM78) += lm78.o +obj-$(CONFIG_SENSORS_LM80) += lm80.o +obj-$(CONFIG_SENSORS_LM83) += lm83.o +obj-$(CONFIG_SENSORS_LM85) += lm85.o +obj-$(CONFIG_SENSORS_LM87) += lm87.o +obj-$(CONFIG_SENSORS_LM90) += lm90.o +obj-$(CONFIG_SENSORS_LM92) += lm92.o +obj-$(CONFIG_SENSORS_MAX1619) += max1619.o +obj-$(CONFIG_SENSORS_PC87360) += pc87360.o +obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o +obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o +obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o +obj-$(CONFIG_SENSORS_VIA686A) += via686a.o +obj-$(CONFIG_SENSORS_W83627EHF) += w83627ehf.o +obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o + +ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y) +EXTRA_CFLAGS += -DDEBUG +endif + diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -1,410 +1,12 @@ # -# I2C Sensor and "other" chip configuration +# Miscellaneous I2C chip drivers configuration # -menu "Hardware Sensors Chip support" - depends on I2C - config I2C_SENSOR tristate default n -config SENSORS_ADM1021 - tristate "Analog Devices ADM1021 and compatibles" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM1021 - and ADM1023 sensor chips and clones: Maxim MAX1617 and MAX1617A, - Genesys Logic GL523SM, National Semiconductor LM84, TI THMC10, - and the XEON processor built-in sensor. - - This driver can also be built as a module. If so, the module - will be called adm1021. - -config SENSORS_ADM1025 - tristate "Analog Devices ADM1025 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM1025 - and Philips NE1619 sensor chips. - - This driver can also be built as a module. If so, the module - will be called adm1025. - -config SENSORS_ADM1026 - tristate "Analog Devices ADM1026 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM1026 - sensor chip. - - This driver can also be built as a module. If so, the module - will be called adm1026. - -config SENSORS_ADM1031 - tristate "Analog Devices ADM1031 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM1031 - and ADM1030 sensor chips. - - This driver can also be built as a module. If so, the module - will be called adm1031. - -config SENSORS_ADM9240 - tristate "Analog Devices ADM9240 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Analog Devices ADM9240, - Dallas DS1780, National Semiconductor LM81 sensor chips. - - This driver can also be built as a module. If so, the module - will be called adm9240. - -config SENSORS_ASB100 - tristate "Asus ASB100 Bach" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for the ASB100 Bach sensor - chip found on some Asus mainboards. - - This driver can also be built as a module. If so, the module - will be called asb100. - -config SENSORS_ATXP1 - tristate "Attansic ATXP1 VID controller" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for the Attansic ATXP1 VID - controller. - - If your board have such a chip, you are able to control your CPU - core and other voltages. - - This driver can also be built as a module. If so, the module - will be called atxp1. - -config SENSORS_DS1621 - tristate "Dallas Semiconductor DS1621 and DS1625" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Dallas Semiconductor - DS1621 and DS1625 sensor chips. - - This driver can also be built as a module. If so, the module - will be called ds1621. - -config SENSORS_FSCHER - tristate "FSC Hermes" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Fujitsu Siemens - Computers Hermes sensor chips. - - This driver can also be built as a module. If so, the module - will be called fscher. - -config SENSORS_FSCPOS - tristate "FSC Poseidon" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Fujitsu Siemens - Computers Poseidon sensor chips. - - This driver can also be built as a module. If so, the module - will be called fscpos. - -config SENSORS_GL518SM - tristate "Genesys Logic GL518SM" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for Genesys Logic GL518SM - sensor chips. - - This driver can also be built as a module. If so, the module - will be called gl518sm. - -config SENSORS_GL520SM - tristate "Genesys Logic GL520SM" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for Genesys Logic GL520SM - sensor chips. - - This driver can also be built as a module. If so, the module - will be called gl520sm. - -config SENSORS_IT87 - tristate "ITE IT87xx and compatibles" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for ITE IT87xx sensor chips - and clones: SiS960. - - This driver can also be built as a module. If so, the module - will be called it87. - -config SENSORS_LM63 - tristate "National Semiconductor LM63" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for the National Semiconductor - LM63 remote diode digital temperature sensor with integrated fan - control. Such chips are found on the Tyan S4882 (Thunder K8QS Pro) - motherboard, among others. - - This driver can also be built as a module. If so, the module - will be called lm63. - -config SENSORS_LM75 - tristate "National Semiconductor LM75 and compatibles" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM75 - sensor chips and clones: Dallas Semiconductor DS75 and DS1775 (in - 9-bit precision mode), and TelCom (now Microchip) TCN75. - - The DS75 and DS1775 in 10- to 12-bit precision modes will require - a force module parameter. The driver will not handle the extra - precision anyhow. - - This driver can also be built as a module. If so, the module - will be called lm75. - -config SENSORS_LM77 - tristate "National Semiconductor LM77" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM77 - sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm77. - -config SENSORS_LM78 - tristate "National Semiconductor LM78 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM78, - LM78-J and LM79. - - This driver can also be built as a module. If so, the module - will be called lm78. - -config SENSORS_LM80 - tristate "National Semiconductor LM80" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor - LM80 sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm80. - -config SENSORS_LM83 - tristate "National Semiconductor LM83" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor - LM83 sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm83. - -config SENSORS_LM85 - tristate "National Semiconductor LM85 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM85 - sensor chips and clones: ADT7463, EMC6D100, EMC6D102 and ADM1027. - - This driver can also be built as a module. If so, the module - will be called lm85. - -config SENSORS_LM87 - tristate "National Semiconductor LM87" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM87 - sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm87. - -config SENSORS_LM90 - tristate "National Semiconductor LM90 and compatibles" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM90, - LM86, LM89 and LM99, Analog Devices ADM1032 and Maxim MAX6657 and - MAX6658 sensor chips. - - The Analog Devices ADT7461 sensor chip is also supported, but only - if found in ADM1032 compatibility mode. - - This driver can also be built as a module. If so, the module - will be called lm90. - -config SENSORS_LM92 - tristate "National Semiconductor LM92 and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for National Semiconductor LM92 - and Maxim MAX6635 sensor chips. - - This driver can also be built as a module. If so, the module - will be called lm92. - -config SENSORS_MAX1619 - tristate "Maxim MAX1619 sensor chip" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for MAX1619 sensor chip. - - This driver can also be built as a module. If so, the module - will be called max1619. - -config SENSORS_PC87360 - tristate "National Semiconductor PC87360 family" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get access to the hardware monitoring - functions of the National Semiconductor PC8736x Super-I/O chips. - The PC87360, PC87363 and PC87364 only have fan monitoring and - control. The PC87365 and PC87366 additionally have voltage and - temperature monitoring. - - This driver can also be built as a module. If so, the module - will be called pc87360. - -config SENSORS_SMSC47B397 - tristate "SMSC LPC47B397-NC" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the SMSC LPC47B397-NC - sensor chip. - - This driver can also be built as a module. If so, the module - will be called smsc47b397. - -config SENSORS_SIS5595 - tristate "Silicon Integrated Systems Corp. SiS5595" - depends on I2C && PCI && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the integrated sensors in - SiS5595 South Bridges. - - This driver can also be built as a module. If so, the module - will be called sis5595. - -config SENSORS_SMSC47M1 - tristate "SMSC LPC47M10x and compatibles" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the integrated fan - monitoring and control capabilities of the SMSC LPC47B27x, - LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192 chips. - - This driver can also be built as a module. If so, the module - will be called smsc47m1. - -config SENSORS_VIA686A - tristate "VIA686A" - depends on I2C && PCI - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the integrated sensors in - Via 686A/B South Bridges. - - This driver can also be built as a module. If so, the module - will be called via686a. - -config SENSORS_W83781D - tristate "Winbond W83781D, W83782D, W83783S, W83627HF, Asus AS99127F" - depends on I2C - select I2C_SENSOR - help - If you say yes here you get support for the Winbond W8378x series - of sensor chips: the W83781D, W83782D, W83783S and W83627HF, - and the similar Asus AS99127F. - - This driver can also be built as a module. If so, the module - will be called w83781d. - -config SENSORS_W83L785TS - tristate "Winbond W83L785TS-S" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - help - If you say yes here you get support for the Winbond W83L785TS-S - sensor chip, which is used on the Asus A7N8X, among other - motherboards. - - This driver can also be built as a module. If so, the module - will be called w83l785ts. - -config SENSORS_W83627HF - tristate "Winbond W83627HF, W83627THF, W83637HF, W83697HF" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get support for the Winbond W836X7 series - of sensor chips: the W83627HF, W83627THF, W83637HF, and the W83697HF - - This driver can also be built as a module. If so, the module - will be called w83627hf. - -config SENSORS_W83627EHF - tristate "Winbond W83627EHF" - depends on I2C && EXPERIMENTAL - select I2C_SENSOR - select I2C_ISA - help - If you say yes here you get preliminary support for the hardware - monitoring functionality of the Winbond W83627EHF Super-I/O chip. - Only fan and temperature inputs are supported at the moment, while - the chip does much more than that. - - This driver can also be built as a module. If so, the module - will be called w83627ehf. - -endmenu - -menu "Other I2C Chip support" +menu "Miscellaneous I2C Chip support" depends on I2C config SENSORS_DS1337 diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile --- a/drivers/i2c/chips/Makefile +++ b/drivers/i2c/chips/Makefile @@ -1,52 +1,16 @@ # -# Makefile for sensor and "other" I2C chip drivers. +# Makefile for miscellaneous I2C chip drivers. # -# asb100, then w83781d go first, as they can override other drivers' addresses. -obj-$(CONFIG_SENSORS_ASB100) += asb100.o -obj-$(CONFIG_SENSORS_W83627HF) += w83627hf.o -obj-$(CONFIG_SENSORS_W83781D) += w83781d.o - -obj-$(CONFIG_SENSORS_ADM1021) += adm1021.o -obj-$(CONFIG_SENSORS_ADM1025) += adm1025.o -obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o -obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o -obj-$(CONFIG_SENSORS_ADM9240) += adm9240.o -obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o obj-$(CONFIG_SENSORS_DS1337) += ds1337.o obj-$(CONFIG_SENSORS_DS1374) += ds1374.o -obj-$(CONFIG_SENSORS_DS1621) += ds1621.o obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o -obj-$(CONFIG_SENSORS_FSCHER) += fscher.o -obj-$(CONFIG_SENSORS_FSCPOS) += fscpos.o -obj-$(CONFIG_SENSORS_GL518SM) += gl518sm.o -obj-$(CONFIG_SENSORS_GL520SM) += gl520sm.o -obj-$(CONFIG_SENSORS_IT87) += it87.o -obj-$(CONFIG_SENSORS_LM63) += lm63.o -obj-$(CONFIG_SENSORS_LM75) += lm75.o -obj-$(CONFIG_SENSORS_LM77) += lm77.o -obj-$(CONFIG_SENSORS_LM78) += lm78.o -obj-$(CONFIG_SENSORS_LM80) += lm80.o -obj-$(CONFIG_SENSORS_LM83) += lm83.o -obj-$(CONFIG_SENSORS_LM85) += lm85.o -obj-$(CONFIG_SENSORS_LM87) += lm87.o -obj-$(CONFIG_SENSORS_LM90) += lm90.o -obj-$(CONFIG_SENSORS_LM92) += lm92.o -obj-$(CONFIG_SENSORS_MAX1619) += max1619.o obj-$(CONFIG_SENSORS_MAX6875) += max6875.o obj-$(CONFIG_SENSORS_M41T00) += m41t00.o -obj-$(CONFIG_SENSORS_PC87360) += pc87360.o obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o obj-$(CONFIG_SENSORS_RTC8564) += rtc8564.o -obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o -obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o -obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o -obj-$(CONFIG_SENSORS_VIA686A) += via686a.o -obj-$(CONFIG_SENSORS_W83627EHF) += w83627ehf.o -obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o - obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o obj-$(CONFIG_TPS65010) += tps65010.o ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2005-07-12 0:04 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-11 22:01 [GIT PATCH] I2C patches for 2.6.13-rc2 Greg KH 2005-07-12 0:03 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: max6875 documentation update Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: max6875 Kconfig update Greg KH 2005-07-12 0:03 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: drop bogus eeprom comment Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: Strip trailing whitespace from strings Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: m41t00: fix incorrect kfree Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: Coding style cleanups to via686a Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: minor TPS6501x cleanups Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: New max6875 driver may corrupt EEPROMs Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] i2c: make better use of IDR in i2c-core Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] w1: fix CRC calculation on bigendian platforms Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: Clarify the usage of i2c-dev.h Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: minor I2C doc cleanups Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: SENSORS_ATXP1 must select I2C_SENSOR Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: Documentation fix Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH 2005-07-11 22:02 ` [PATCH] I2C: Move hwmon drivers (1/3) Greg KH 2005-07-12 0:04 ` [lm-sensors] " Greg KH
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.