diff options
| author | Jean Delvare <khali@linux-fr.org> | 2005-08-09 20:28:10 +0200 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@suse.de> | 2005-09-05 09:14:25 -0700 |
| commit | 4c9337da37c877e53a64696fc8524f642d446cba (patch) | |
| tree | 30f34691bd61b55b11ec19f6fbc27ae69886eff8 /drivers/i2c/chips | |
| parent | a89ba0bc02e82920a0f4137aa5d655ac0366cc28 (diff) | |
| download | op-kernel-dev-4c9337da37c877e53a64696fc8524f642d446cba.zip op-kernel-dev-4c9337da37c877e53a64696fc8524f642d446cba.tar.gz | |
[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.c | 5 | ||||
| -rw-r--r-- | drivers/i2c/chips/max6875.c | 5 |
2 files changed, 0 insertions, 10 deletions
diff --git a/drivers/i2c/chips/eeprom.c b/drivers/i2c/chips/eeprom.c index a27420a..d58403a 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) 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) diff --git a/drivers/i2c/chips/max6875.c b/drivers/i2c/chips/max6875.c index 31cee2d..9e1aeb6 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) 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); - if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WRITE_BYTE_DATA | I2C_FUNC_SMBUS_READ_BYTE)) return 0; |
