421ef47be2
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> |
||
---|---|---|
.. | ||
acorn | ||
acpi | ||
atm | ||
base | ||
block | ||
bluetooth | ||
cdrom | ||
char | ||
connector | ||
cpufreq | ||
crypto | ||
dio | ||
eisa | ||
fc4 | ||
firmware | ||
hwmon | ||
i2c | ||
ide | ||
ieee1394 | ||
infiniband | ||
input | ||
isdn | ||
macintosh | ||
mca | ||
md | ||
media | ||
message | ||
mfd | ||
misc | ||
mmc | ||
mtd | ||
net | ||
nubus | ||
oprofile | ||
parisc | ||
parport | ||
pci | ||
pcmcia | ||
pnp | ||
s390 | ||
sbus | ||
scsi | ||
serial | ||
sh | ||
sn | ||
tc | ||
telephony | ||
usb | ||
video | ||
w1 | ||
zorro | ||
Kconfig | ||
Makefile |