2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-20 03:04:01 +08:00
linux-next/drivers/i2c
Jean Delvare 421ef47be2 [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>
2005-10-28 14:02:14 -07:00
..
algos [PATCH] i2c: Discard explicit static initializations to 0 2005-10-28 14:02:06 -07:00
busses [PATCH] i2c: SMBus PEC support rewrite, 1 of 3 2005-10-28 14:02:13 -07:00
chips [PATCH] i2c: Static function fixes, 4 of 4 2005-10-28 14:02:13 -07:00
i2c-core.c [PATCH] i2c: SMBus PEC support rewrite, 2 of 3 2005-10-28 14:02:14 -07:00
i2c-dev.c [PATCH] i2c: kzalloc conversion, other drivers 2005-10-28 14:02:12 -07:00
Kconfig Linux-2.6.12-rc2 2005-04-16 15:20:36 -07:00
Makefile [PATCH] hwmon: hwmon vs i2c, second round (07/11) 2005-09-05 09:14:22 -07:00