linux-stable.git/drivers/i2c, branch linux-2.6.34.y Linux kernel stable tree i2c-algo-bit: Generate correct i2c address sequence for 10-bit target 2013-01-16T21:44:57+00:00 Jeffrey (Sheng-Hui) Chu jeffchu@broadcom.com 2011-11-23T10:33:07+00:00 50dbd6f1b370a57cd90eb49a01a5ee732242bbaf commit cc6bcf7d2ec2234e7b41770185e4dc826390185e upstream. The wrong bits were put on the wire, fix that. This fixes kernel bug #42562. Signed-off-by: Sheng-Hui J. Chu <jeffchu@broadcom.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 
commit cc6bcf7d2ec2234e7b41770185e4dc826390185e upstream.

The wrong bits were put on the wire, fix that.

This fixes kernel bug #42562.

Signed-off-by: Sheng-Hui J. Chu <jeffchu@broadcom.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
i2c-taos-evm: Fix log messages 2012-05-17T15:21:01+00:00 Jean Delvare khali@linux-fr.org 2011-06-29T09:36:10+00:00 586cfeb0949b95042a25a1f8ba0937ed8aba70bb commit 9b640f2e154268cb516efcaf9c434f2e73c6783e upstream. * Print all error and information messages even when debugging is disabled. * Don't use adapter device to log messages before it is ready. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 
commit 9b640f2e154268cb516efcaf9c434f2e73c6783e upstream.

* Print all error and information messages even when debugging is
  disabled.
* Don't use adapter device to log messages before it is ready.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
i2c: Unregister dummy devices last on adapter removal 2011-06-26T16:46:30+00:00 Jean Delvare khali@linux-fr.org 2011-01-14T21:03:49+00:00 5221f73c8309a8cde70909c7b852350f7cd4b203 commit 5219bf884b6e2b54e734ca1799b6f0014bb2b4b7 upstream. Remove real devices first and dummy devices last. This gives device driver which instantiated dummy devices themselves a chance to clean them up before we do. Signed-off-by: Jean Delvare <khali@linux-fr.org> Tested-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 
commit 5219bf884b6e2b54e734ca1799b6f0014bb2b4b7 upstream.

Remove real devices first and dummy devices last. This gives device
driver which instantiated dummy devices themselves a chance to clean
them up before we do.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
i2c-pca-platform: Change device name of request_irq 2011-04-17T20:15:37+00:00 Nobuhiro Iwamatsu nobuhiro.iwamatsu.yj@renesas.com 2010-10-24T16:16:57+00:00 06b5b28644d92e9de4658d98d9e0aaa6599f029d commit 323584436db0cb05286425d4dfd9516fce88487f upstream. i2c->adap.name shouldn't be used in request_irq. Instead the driver name "i2c-pca-platform" should be used. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 
commit 323584436db0cb05286425d4dfd9516fce88487f upstream.

i2c->adap.name shouldn't be used in request_irq.
Instead the driver name "i2c-pca-platform" should be used.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
i2c-pca: Fix waitforcompletion() return value 2011-01-06T23:08:11+00:00 Yegor Yefremov yegor_sub1@visionsystems.de 2010-09-30T12:14:22+00:00 388a1771e497f0b78c8993e0259316673d5bc840 commit 6abb930af064fb1cf4177d32e2c7bfb89eee0fe5 upstream. ret is still -1, if during the polling read_byte() returns at once with I2C_PCA_CON_SI set. So ret > 0 would lead *_waitforcompletion() to return 0, in spite of the proper behavior. The routine was rewritten, so that ret has always a proper value, before returning. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Reviewed-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 
commit 6abb930af064fb1cf4177d32e2c7bfb89eee0fe5 upstream.

ret is still -1, if during the polling read_byte() returns at once
with I2C_PCA_CON_SI set. So ret > 0 would lead *_waitforcompletion()
to return 0, in spite of the proper behavior.

The routine was rewritten, so that ret has always a proper value,
before returning.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
i2c-core: Use per-adapter userspace device lists 2010-05-04T09:09:28+00:00 Jean Delvare khali@linux-fr.org 2010-05-04T09:09:28+00:00 6629dcff19470a894ce294d0adb9cbab94ee1fb9 Using a single list for all userspace devices leads to a dead lock on multiplexed buses in some circumstances (mux chip instantiated from userspace). This is solved by using a separate list for each bus segment. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Michael Lawnick <ml.lawnick@gmx.de> 
Using a single list for all userspace devices leads to a dead lock
on multiplexed buses in some circumstances (mux chip instantiated
from userspace). This is solved by using a separate list for each
bus segment.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Michael Lawnick <ml.lawnick@gmx.de>
i2c: Fix probing of FSC hardware monitoring chips 2010-05-04T09:09:28+00:00 Jean Delvare khali@linux-fr.org 2010-05-04T09:09:28+00:00 b1d4b390ea4bb480e65974ce522a04022608a8df Some FSC hardware monitoring chips (Syleus at least) doesn't like quick writes we typically use to probe for I2C chips. Use a regular byte read instead for the address they live at (0x73). These are the only known chips living at this address on PC systems. For clarity, this fix should not be needed for kernels 2.6.30 and later, as we started instantiating the hwmon devices explicitly based on DMI data. Still, this fix is valuable in the following two cases: * Support for recent FSC chips on older kernels. The DMI-based device instantiation is more difficult to backport than the device support itself. * Case where the DMI-based device instantiation fails, whatever the reason. We fall back to probing in that case, so it should work. This fixes kernel bug #15634: https://bugzilla.kernel.org/show_bug.cgi?id=15634 Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Cc: stable@kernel.org 
Some FSC hardware monitoring chips (Syleus at least) doesn't like
quick writes we typically use to probe for I2C chips. Use a regular
byte read instead for the address they live at (0x73). These are the
only known chips living at this address on PC systems.

For clarity, this fix should not be needed for kernels 2.6.30 and
later, as we started instantiating the hwmon devices explicitly based
on DMI data. Still, this fix is valuable in the following two cases:
* Support for recent FSC chips on older kernels. The DMI-based device
  instantiation is more difficult to backport than the device support
  itself.
* Case where the DMI-based device instantiation fails, whatever the
  reason. We fall back to probing in that case, so it should work.

This fixes kernel bug #15634:
https://bugzilla.kernel.org/show_bug.cgi?id=15634

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@kernel.org
i2c-core: Erase pointer to clientdata on removal 2010-05-04T09:09:27+00:00 Wolfram Sang w.sang@pengutronix.de 2010-05-04T09:09:27+00:00 e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 After discovering that a lot of i2c-drivers leave the pointer to their clientdata dangling, it was decided to let the core handle this issue. It is assumed that the core may access the private data after remove() as there are no guarantees for the lifetime of such pointers anyhow (see thread starting at http://lkml.org/lkml/2010/3/21/68) Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Jean Delvare <khali@linux-fr.org> 
After discovering that a lot of i2c-drivers leave the pointer to their
clientdata dangling, it was decided to let the core handle this issue.
It is assumed that the core may access the private data after remove()
as there are no guarantees for the lifetime of such pointers anyhow (see
thread starting at http://lkml.org/lkml/2010/3/21/68)

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
I2C: Fix section mismatch errors in i2c-octeon.c 2010-04-30T19:52:52+00:00 David Daney ddaney@caviumnetworks.com 2010-03-08T19:04:21+00:00 20f12160607c09e299a3e93c7bf4d75e8801c9b7 Signed-off-by: David Daney <ddaney@caviumnetworks.com> To: linux-i2c@vger.kernel.org To: ben-linux@fluff.org To: khali@linux-fr.org Cc: linux-mips@linux-mips.org Cc: rade.bozic.ext@nsn.com Patchwork: http://patchwork.linux-mips.org/patch/1037/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-i2c@vger.kernel.org
To: ben-linux@fluff.org
To: khali@linux-fr.org
Cc: linux-mips@linux-mips.org
Cc: rade.bozic.ext@nsn.com
Patchwork: http://patchwork.linux-mips.org/patch/1037/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
i2c-stu300: off by one issue 2010-04-20T00:17:13+00:00 Dan Carpenter error27@gmail.com 2010-04-07T09:22:58+00:00 42df64b1f83fa9b786067a0b5a3aca0fbb2d8db8 If we don't find the correct rate, we want to end the loop with "i" pointing to the last element in the array. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Ben Dooks <ben-linux@fluff.org> 
If we don't find the correct rate, we want to end the loop with "i"
pointing to the last element in the array.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>