Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ed6bafbf6017d6a007b39de6b65ad3b8ae4c8aee
Commit: ed6bafbf6017d6a007b39de6b65ad3b8ae4c8aee
Parent: 7f999aa726ded3fd10d7619945e8b7d7e39833b3
Author: Jean Delvare <[EMAIL PROTECTED]>
AuthorDate: Wed Feb 14 21:15:03 2007 +0100
Committer: Jean Delvare <[EMAIL PROTECTED]>
CommitDate: Wed Feb 14 21:15:03 2007 +0100
hwmon: Cleanup a bogus legacy comment
Cleanup a bogus legacy comment that has been replicated to many
hardware monitoring drivers.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/hwmon/it87.c | 6 ++----
drivers/hwmon/lm78.c | 6 ++----
drivers/hwmon/lm85.c | 7 ++-----
drivers/hwmon/sis5595.c | 6 ++----
drivers/hwmon/via686a.c | 5 ++---
drivers/hwmon/w83627hf.c | 5 ++---
drivers/hwmon/w83781d.c | 10 ++--------
7 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
index 18bb44d..62afc63 100644
--- a/drivers/hwmon/it87.c
+++ b/drivers/hwmon/it87.c
@@ -214,10 +214,8 @@ static const unsigned int pwm_freq[8] = {
};
-/* For each registered IT87, we need to keep some data in memory. That
- data is pointed to by it87_list[NR]->data. The structure itself is
- dynamically allocated, at the same time when a new it87 client is
- allocated. */
+/* For each registered chip, we need to keep some data in memory.
+ The structure is dynamically allocated. */
struct it87_data {
struct i2c_client client;
struct class_device *class_dev;
diff --git a/drivers/hwmon/lm78.c b/drivers/hwmon/lm78.c
index 73bc2ff..886786c 100644
--- a/drivers/hwmon/lm78.c
+++ b/drivers/hwmon/lm78.c
@@ -125,10 +125,8 @@ static inline int TEMP_FROM_REG(s8 val)
bad. Quite a lot of bookkeeping is done. A real driver can often cut
some corners. */
-/* For each registered LM78, we need to keep some data in memory. That
- data is pointed to by lm78_list[NR]->data. The structure itself is
- dynamically allocated, at the same time when a new lm78 client is
- allocated. */
+/* For each registered chip, we need to keep some data in memory.
+ The structure is dynamically allocated. */
struct lm78_data {
struct i2c_client client;
struct class_device *class_dev;
diff --git a/drivers/hwmon/lm85.c b/drivers/hwmon/lm85.c
index bb7a136..20a8c64 100644
--- a/drivers/hwmon/lm85.c
+++ b/drivers/hwmon/lm85.c
@@ -298,11 +298,6 @@ static int ZONE_TO_REG( int zone )
#define LM85_DATA_INTERVAL (HZ + HZ / 2)
#define LM85_CONFIG_INTERVAL (1 * 60 * HZ)
-/* For each registered LM85, we need to keep some data in memory. That
- data is pointed to by lm85_list[NR]->data. The structure itself is
- dynamically allocated, at the same time when a new lm85 client is
- allocated. */
-
/* LM85 can automatically adjust fan speeds based on temperature
* This structure encapsulates an entire Zone config. There are
* three zones (one for each temperature input) on the lm85
@@ -329,6 +324,8 @@ struct lm85_autofan {
u8 min_off; /* Min PWM or OFF below "limit", flag */
};
+/* For each registered chip, we need to keep some data in memory.
+ The structure is dynamically allocated. */
struct lm85_data {
struct i2c_client client;
struct class_device *class_dev;
diff --git a/drivers/hwmon/sis5595.c b/drivers/hwmon/sis5595.c
index 95a4b5d..3f40026 100644
--- a/drivers/hwmon/sis5595.c
+++ b/drivers/hwmon/sis5595.c
@@ -162,10 +162,8 @@ static inline u8 DIV_TO_REG(int val)
}
#define DIV_FROM_REG(val) (1 << (val))
-/* For the SIS5595, we need to keep some data in memory. That
- data is pointed to by sis5595_list[NR]->data. The structure itself is
- dynamically allocated, at the time when the new sis5595 client is
- allocated. */
+/* For each registered chip, we need to keep some data in memory.
+ The structure is dynamically allocated. */
struct sis5595_data {
struct i2c_client client;
struct class_device *class_dev;
diff --git a/drivers/hwmon/via686a.c b/drivers/hwmon/via686a.c
index f8acada..9a440c8 100644
--- a/drivers/hwmon/via686a.c
+++ b/drivers/hwmon/via686a.c
@@ -292,9 +292,8 @@ static inline long TEMP_FROM_REG10(u16 val)
#define DIV_FROM_REG(val) (1 << (val))
#define DIV_TO_REG(val) ((val)==8?3:(val)==4?2:(val)==1?0:1)
-/* For the VIA686A, we need to keep some data in memory.
- The structure is dynamically allocated, at the same time when a new
- via686a client is allocated. */
+/* For each registered chip, we need to keep some data in memory.
+ The structure is dynamically allocated. */
struct via686a_data {
struct i2c_client client;
struct class_device *class_dev;
diff --git a/drivers/hwmon/w83627hf.c b/drivers/hwmon/w83627hf.c
index dfdc29c..d7e2406 100644
--- a/drivers/hwmon/w83627hf.c
+++ b/drivers/hwmon/w83627hf.c
@@ -286,9 +286,8 @@ static inline u8 DIV_TO_REG(long val)
return ((u8) i);
}
-/* For each registered chip, we need to keep some data in memory. That
- data is pointed to by w83627hf_list[NR]->data. The structure itself is
- dynamically allocated, at the same time when a new client is allocated. */
+/* For each registered chip, we need to keep some data in memory.
+ The structure is dynamically allocated. */
struct w83627hf_data {
struct i2c_client client;
struct class_device *class_dev;
diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
index 1232171..a47da3e 100644
--- a/drivers/hwmon/w83781d.c
+++ b/drivers/hwmon/w83781d.c
@@ -221,14 +221,8 @@ DIV_TO_REG(long val, enum chips type)
a bit - except if there could be more than one SMBus. Groan. No solution
for this yet. */
-/* This module may seem overly long and complicated. In fact, it is not so
- bad. Quite a lot of bookkeeping is done. A real driver can often cut
- some corners. */
-
-/* For each registered W83781D, we need to keep some data in memory. That
- data is pointed to by w83781d_list[NR]->data. The structure itself is
- dynamically allocated, at the same time when a new w83781d client is
- allocated. */
+/* For each registered chip, we need to keep some data in memory.
+ The structure is dynamically allocated. */
struct w83781d_data {
struct i2c_client client;
struct class_device *class_dev;
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
