aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/i2c/chips
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2005-08-09 14:28:10 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2005-09-05 12:14:25 -0400
commit4c9337da37c877e53a64696fc8524f642d446cba (patch)
tree30f34691bd61b55b11ec19f6fbc27ae69886eff8 /drivers/i2c/chips
parenta89ba0bc02e82920a0f4137aa5d655ac0366cc28 (diff)
[PATCH] I2C: Centralize 24RF08 corruption prevention
The 24RF08 corruption would better be prevented at i2c-core level than at chip driver level, for several reasons: * The second quick write should happen as soon as possible after the first one, so as to limit the risk that another command is issued on the bus inbetween, causing the corruption. * As a matter of fact, the protection code at driver level was reworked at least three times already, which proves how hard it is to get it right there, while it's straightforward at i2c-core level. * It's easy to add a new driver that would need the protection, and forget to add it. This did happen already. * As additional probing addresses can be passed to most i2c chip drivers as module parameters, virtually every i2c chip driver would need the protection if we want to be really safe. * Why duplicate code when we can easily avoid it? Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/i2c/chips')
-rw-r--r--drivers/i2c/chips/eeprom.c5
-rw-r--r--drivers/i2c/chips/max6875.c5
2 files changed, 0 insertions, 10 deletions
diff --git a/drivers/i2c/chips/eeprom.c b/drivers/i2c/chips/eeprom.c
index a27420a54c84..d58403a47908 100644
--- a/drivers/i2c/chips/eeprom.c
+++ b/drivers/i2c/chips/eeprom.c
@@ -161,11 +161,6 @@ int eeprom_detect(struct i2c_adapter *adapter, int address, int kind)
161 struct eeprom_data *data; 161 struct eeprom_data *data;
162 int err = 0; 162 int err = 0;
163 163
164 /* prevent 24RF08 corruption */
165 if (kind < 0)
166 i2c_smbus_xfer(adapter, address, 0, 0, 0,
167 I2C_SMBUS_QUICK, NULL);
168
169 /* There are three ways we can read the EEPROM data: 164 /* There are three ways we can read the EEPROM data:
170 (1) I2C block reads (faster, but unsupported by most adapters) 165 (1) I2C block reads (faster, but unsupported by most adapters)
171 (2) Consecutive byte reads (100% overhead) 166 (2) Consecutive byte reads (100% overhead)
diff --git a/drivers/i2c/chips/max6875.c b/drivers/i2c/chips/max6875.c
index 31cee2d34a17..9e1aeb69abf9 100644
--- a/drivers/i2c/chips/max6875.c
+++ b/drivers/i2c/chips/max6875.c
@@ -171,11 +171,6 @@ static int max6875_detect(struct i2c_adapter *adapter, int address, int kind)
171 struct max6875_data *data; 171 struct max6875_data *data;
172 int err = 0; 172 int err = 0;
173 173
174 /* Prevent 24rf08 corruption (in case of user error) */
175 if (kind < 0)
176 i2c_smbus_xfer(adapter, address, 0, 0, 0,
177 I2C_SMBUS_QUICK, NULL);
178
179 if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WRITE_BYTE_DATA 174 if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WRITE_BYTE_DATA
180 | I2C_FUNC_SMBUS_READ_BYTE)) 175 | I2C_FUNC_SMBUS_READ_BYTE))
181 return 0; 176 return 0;