You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

Jean Delvare 4c9337da37 [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>		20 years ago
..
busses	…
chips	[PATCH] I2C: max6875 documentation cleanup	20 years ago
dev-interface	[PATCH] I2C: Clarify the usage of i2c-dev.h	20 years ago
functionality	[PATCH] I2C: fix typo in documentation	20 years ago
i2c-protocol	…
i2c-stub	…
porting-clients	[PATCH] I2C: Centralize 24RF08 corruption prevention	20 years ago
smbus-protocol	…
summary	…
ten-bit-addresses	…
writing-clients	[PATCH] I2C: Rewrite i2c_probe	20 years ago