aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2005-10-26 15:28:55 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2005-10-28 17:02:14 -0400
commit421ef47be20c5454b12ae0ec918d5073a9d2b938 (patch)
treea7225bd055acb418693d0e6ed4f8d886dc68ec55 /include/linux
parentb8095544bc27044a7aa79e1e073b781a249910c3 (diff)
[PATCH] i2c: SMBus PEC support rewrite, 2 of 3
This is my rewrite of the SMBus PEC support. The original implementation was known to have bugs (credits go to Hideki Iwamoto for reporting many of them recently), and was incomplete due to a conceptual limitation. The rewrite affects only software PEC. Hardware PEC needs very little code and is mostly untouched. Technically, both implementations differ in that the original one was emulating PEC in software by modifying the contents of an i2c_smbus_data union (changing the transaction to a different type), while the new one works one level lower, on i2c_msg structures (working on message contents). Due to the definition of the i2c_smbus_data union, not all SMBus transactions could be handled (at least not without changing the definition of this union, which would break user-space compatibility), and those which could had to be implemented individually. At the opposite, adding PEC to an i2c_msg structure can be done on any SMBus transaction with common code. Advantages of the new implementation: * It's about twice as small (from ~136 lines before to ~70 now, only counting i2c-core, including blank and comment lines). The memory used by i2c-core is down by ~640 bytes (~3.5%). * Easier to validate, less tricky code. The code being common to all transactions by design, the risk that a bug can stay uncovered is lower. * All SMBus transactions have PEC support in I2C emulation mode (providing the non-PEC transaction is also implemented). Transactions which have no emulation code right now will get PEC support for free when they finally get implemented. * Allows for code simplifications in header files and bus drivers (patch follows). Drawbacks (I guess there had to be at least one): * PEC emulation for non-PEC capable non-I2C SMBus masters was dropped. It was based on SMBus tricks and doesn't quite fit in the new design. I don't think it's really a problem, as the benefit was certainly not worth the additional complexity, but it's only fair that I at least mention it. Lastly, let's note that the new implementation does slightly affect compatibility (both in kernel and user-space), but doesn't actually break it. Some defines will be dropped, but the code can always be changed in a way that will work with both the old and the new implementations. It shouldn't be a problem as there doesn't seem to be many users of SMBus PEC to date anyway. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'include/linux')
-rw-r--r--include/linux/i2c.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index bcd4bb1b450c..78c64f7b3105 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -434,7 +434,7 @@ union i2c_smbus_data {
434 __u8 byte; 434 __u8 byte;
435 __u16 word; 435 __u16 word;
436 __u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for length */ 436 __u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for length */
437 /* and one more for PEC */ 437 /* and one more for user-space compatibility */
438}; 438};
439 439
440/* smbus_access read or write markers */ 440/* smbus_access read or write markers */