[ Upstream commit 0a355aeb24081e4538d4d424cd189f16c0bbd983 ] If something goes wrong (such as the SCL being stuck low) then we need to reset the PCA chip. The issue with this is that on reset we lose all config settings and the chip ends up in a disabled state which results in a lock up/high CPU usage. We need to re-apply any configuration that had previously been set and re-enable the chip. Signed-off-by: Evan Nimmo <evan.nimmo@alliedtelesis.co.nz> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit cd217f2300793a106b49c7dfcbfb26e348bc7593 ]
The PCA9665 datasheet says that I2CSTA = 78h indicates that SCL is stuck
low, this differs to the PCA9564 which uses 90h for this indication.
Treat either 0x78 or 0x90 as an indication that the SCL line is stuck.
Based on looking through the PCA9564 and PCA9665 datasheets this should
be safe for both chips. The PCA9564 should not return 0x78 for any valid
state and the PCA9665 should not return 0x90.
Fixes: eff9ec95efaa ("i2c-algo-pca: Add PCA9665 support")
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
We have a central copy of the GPL for that. Some addresses were already outdated. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Pull more i2c updates from Wolfram Sang: "Mostly bugfixes, small but wanted cleanups, and Paul's init.h removal applied" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: rcar: fix NACK error code i2c: update i2c_algorithm documentation i2c: rcar: use devm_clk_get to ensure clock is properly ref-counted i2c: rcar: do not print error if device nacks transfer i2c: rely on driver core when sanitizing devices i2c: delete non-required instances of include <linux/init.h> i2c: acorn: is tristate and should use module.h i2c: piix4: Standardize log messages i2c: piix4: Use different message for AMD Auxiliary SMBus Controller i2c: piix4: Add support for AMD ML and CZ SMBus changes
Signed-off-by: Jean Delvare <khali@linux-fr.org>
None of these files are actually using any __init type directives and hence don't need to include <linux/init.h>. Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Linux 3.6-rc7 Needed to get updates from i2c-embedded/for-current into i2c-embedded/for-next
The parameter passed to pca9665_reset is adap->data (which is bus driver specific), not i2c_algp_pca_data *adap. pca9665_reset expects it to be i2c_algp_pca_data *adap. All other wrappers from the algo call back to the bus driver, which knows to handle its custom data. Only pca9665_reset resides inside the algorithm code and does not know how to handle a custom data structure. This can result in a kernel crash. Fix by re-factoring pca_reset() from a macro to a function handling chip specific code, and only call adap->reset_chip() if the chip is not PCA9665. Signed-off-by: Thomas Kavanagh <tkavanagh@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
The code currently always selects turbo mode for PCA9665, no matter which clock frequency is configured. This is because it compares the clock frequency against constants reflecting (boundary / 100). Compare against real boundary frequencies to fix the problem. Signed-off-by: Thomas Kavanagh <tkavanagh@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>