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>
This patch updates the .owner field for the i2c core struct xxxx_driver
variables.
Signed-off-by: Laurent Riffard <laurent.riffard@free.fr>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Drop I2C_SMBUS_I2C_BLOCK_MAX, use I2C_SMBUS_BLOCK_MAX instead.
I2C_SMBUS_I2C_BLOCK_MAX has always been defined to the same value as
I2C_SMBUS_BLOCK_MAX, and this will never change: setting it to a lower
value would make no sense, setting it to a higher value would break
i2c_smbus_data compatibility. There is no point in changing
i2c_smbus_data to support larger block transactions in SMBus mode, as
no SMBus hardware supports more than 32 byte blocks. Thus, for larger
transactions, direct I2C transfers are the way to go.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move the check for SMBUS_QUICK in i2c_probe() after the forced
addresses have been handled. This makes it possible for a driver to
leave the probed address lists empty, only providing forced addresses,
and get i2c_probe to work even if the bus doesn't support SMBUS_QUICK.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/i2c/i2c-core.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
In PM v1, all devices were called at SUSPEND_DISABLE level. Then
all devices were called at SUSPEND_SAVE_STATE level, and finally
SUSPEND_POWER_DOWN level. However, with PM v2, to maintain
compatibility for platform devices, I arranged for the PM v2
suspend/resume callbacks to call the old PM v1 suspend/resume
callbacks three times with each level in order so that existing
drivers continued to work.
Since this is obsolete infrastructure which is no longer necessary,
we can remove it. Here's an (untested) patch to do exactly that.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
i2c_probe was quite complex and slow, so I rewrote it in a more
efficient and hopefully clearer way.
Note that this slightly changes the way the module parameters are
handled. This shouldn't change anything for the most common cases
though.
For one thing, the function now respects the order of the parameters
for address probing. It used to always do lower addresses first. The
new approach gives the user more control.
For another, ignore addresses don't overrule probe addresses anymore.
This could have been restored the way it was at the cost of a few more
lines of code, but I don't think it's worth it. Both lists are given
as module parameters, so a user would be quite silly to specify the
same addresses in both lists. The normal addresses list is the only
one that isn't controlled by a module parameter, thus is the only one
the user may reasonably want to remove an address from.
Another significant change is the fact that i2c_probe() will no more
stop when a detection function returns -ENODEV. Just because a driver
found a chip it doesn't support isn't a valid reason to stop all
probings for this one driver. This closes the long standing lm_sensors
ticket #1807.
http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1807
I updated the documentation accordingly.
In terms of algorithmic complexity, the new code is way better. If
I is the ignore address count, P the probe address count, N the
normal address count and F the force address count, the old code
was doing 128 * (F + I + P + N) iterations max, while the new code
does F + P + ((I+1) * N) iterations max. For the most common case
where F, I and P are empty, this is down from 128 * N to N.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add support for kind-forced addresses to i2c_probe, like i2c_detect
has for (essentially) hardware monitoring drivers.
Note that this change will slightly increase the size of the drivers
using I2C_CLIENT_INSMOD, with no immediate benefit. This is a
requirement if we want to merge i2c_probe and i2c_detect though, and
seems a reasonable price to pay in comparison with the previous
cleanups which saved much more than that (such as the i2c-isa cleanup
or the i2c address ranges removal.)
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The debugging messages in i2c-core are more confusing than helpful. Some
lack their trailing newline, some lack a prefix, some are redundant,
some lack precious information. Here is my attempt to introduce some
standardization in there.
I also changed two messages in i2c-dev to make it clear they come from
i2c-dev.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We could inline i2c_adapter_id, as it is really, really short. Doing
so saves a few bytes both in i2c-core and in the drivers using this
function.
before after diff
drivers/hwmon/adm1026.ko 41344 41305 -39
drivers/hwmon/asb100.ko 27325 27246 -79
drivers/hwmon/gl518sm.ko 20824 20785 -39
drivers/hwmon/it87.ko 26419 26380 -39
drivers/hwmon/lm78.ko 21424 21385 -39
drivers/hwmon/lm85.ko 41034 40939 -95
drivers/hwmon/w83781d.ko 39561 39514 -47
drivers/hwmon/w83792d.ko 32979 32932 -47
drivers/i2c/i2c-core.ko 24708 24531 -177
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We could refactor the error message 34 different i2c drivers print if
i2c_detach_client() fails in this function itself. Saves quite a few
lines of code. Documentation is updated to reflect that change.
Note that this patch should be applied after Rudolf Marek's w83792d
patches.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Temporarily export a few structures and functions from i2c-core, because we
will soon need them in i2c-isa.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Two log messages lack their trailing new line in i2c-core. I'd swear I had
fixed them already, but it seems not. Bonus: improved coding style.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch uses the already existing IDR mechanism to simplify and
improve the i2c_get_adapter function in i2c-core.
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes a misspelling in a comment section.
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Call i2c_transfer() from i2c_master_send() and i2c_master_recv() to
avoid the redundant code that was in all three functions. It also
removes unnecessary debug statements as suggested by Jean Delvare.
This is important for the non-blocking interfaces because they will
have to handle a non-blocking interface in this area. Having it in
one place greatly simplifies the changes.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Files that don't use CONFIG_* stuff shouldn't include config.h
Files that use CONFIG_* stuff should include config.h
It's that simple. ;-)
Signed-off-by: Alexey Dobriyan <adobriyan@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some months ago, you killed the address ranges mechanism from all
sensors i2c chip drivers (both the module parameters and the in-code
address lists). I think it was a very good move, as the ranges can
easily be replaced by individual addresses, and this allowed for
significant cleanups in the i2c core (let alone the impressive size
shrink for all these drivers).
Unfortunately you did not do the same for non-sensors i2c chip drivers.
These need the address ranges even less, so we could get rid of the
ranges here as well for another significant i2c core cleanup. Here comes
a patch which does just that. Since the process is exactly the same as
what you did for the other drivers set already, I did not split this one
in parts.
A documentation update is included.
The change saves 308 bytes in the i2c core, and an average 1382 bytes
for chip drivers which use I2C_CLIENT_INSMOD, 126 bytes for those which
do not.
This change is required if we want to merge the sensors and non-sensors
i2c code (and we want to do this).
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Index: gregkh-2.6/Documentation/i2c/writing-clients
===================================================================
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Jean Delvare