summaryrefslogtreecommitdiffstats
path: root/drivers/i2c
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2005-07-29 12:15:33 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2005-07-29 13:12:51 -0700
commit0d73adc14e239b05a9393c09c067a26a5ba86b6c (patch)
tree2d37b52c21c02c4f7be2e2551abad3d4cbc69e73 /drivers/i2c
parent86749e8512d2c37618dc5814ef41abbf168f291b (diff)
downloadop-kernel-dev-0d73adc14e239b05a9393c09c067a26a5ba86b6c.zip
op-kernel-dev-0d73adc14e239b05a9393c09c067a26a5ba86b6c.tar.gz
[PATCH] I2C: 24RF08 corruption prevention (again)
The 24RF08 corruption prevention in the eeprom and max6875 drivers wasn't complete. For one thing, the additional quick write should happen as soon as possible and unconditionally, while both drivers had error paths before. For another, when a given chip is forced, the core does not emit a quick write, so a second quick write would cause the corruption rather than prevent it. I plan to move the corruption prevention in the core in the long run, so that individual drivers don't have to care anymore. But I need to merge i2c_probe and i2c_detect before I do (work in progress). Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'drivers/i2c')
-rw-r--r--drivers/i2c/chips/eeprom.c8
-rw-r--r--drivers/i2c/chips/max6875.c8
2 files changed, 10 insertions, 6 deletions
diff --git a/drivers/i2c/chips/eeprom.c b/drivers/i2c/chips/eeprom.c
index 6ea413f..a2da31b 100644
--- a/drivers/i2c/chips/eeprom.c
+++ b/drivers/i2c/chips/eeprom.c
@@ -163,6 +163,11 @@ int eeprom_detect(struct i2c_adapter *adapter, int address, int kind)
struct eeprom_data *data;
int err = 0;
+ /* prevent 24RF08 corruption */
+ if (kind < 0)
+ i2c_smbus_xfer(adapter, address, 0, 0, 0,
+ I2C_SMBUS_QUICK, NULL);
+
/* There are three ways we can read the EEPROM data:
(1) I2C block reads (faster, but unsupported by most adapters)
(2) Consecutive byte reads (100% overhead)
@@ -187,9 +192,6 @@ int eeprom_detect(struct i2c_adapter *adapter, int address, int kind)
new_client->driver = &eeprom_driver;
new_client->flags = 0;
- /* prevent 24RF08 corruption */
- i2c_smbus_write_quick(new_client, 0);
-
/* Fill in the remaining client fields */
strlcpy(new_client->name, "eeprom", I2C_NAME_SIZE);
data->valid = 0;
diff --git a/drivers/i2c/chips/max6875.c b/drivers/i2c/chips/max6875.c
index c4f14d9..0230375 100644
--- a/drivers/i2c/chips/max6875.c
+++ b/drivers/i2c/chips/max6875.c
@@ -343,6 +343,11 @@ static int max6875_detect(struct i2c_adapter *adapter, int address, int kind)
struct max6875_data *data;
int err = 0;
+ /* Prevent 24RF08 corruption (in case of user error) */
+ if (kind < 0)
+ i2c_smbus_xfer(adapter, address, 0, 0, 0,
+ I2C_SMBUS_QUICK, NULL);
+
/* There are three ways we can read the EEPROM data:
(1) I2C block reads (faster, but unsupported by most adapters)
(2) Consecutive byte reads (100% overhead)
@@ -370,9 +375,6 @@ static int max6875_detect(struct i2c_adapter *adapter, int address, int kind)
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;
OpenPOWER on IntegriCloud