summaryrefslogtreecommitdiff
path: root/include/linux/i2c-algo-pca.h
AgeCommit message (Collapse)Author
2020-09-23i2c: algo: pca: Reapply i2c bus settings after resetEvan Nimmo
[ 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>
2012-10-06i2c: algo: pca: Fix chip reset function for PCA9665Thomas Kavanagh
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>
2009-03-28i2c-algo-pca: Add PCA9665 supportMarco Aurelio da Costa
Add support for the PCA9665 I2C controller. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2008-04-22i2c-algo-pca: Extend for future driversWolfram Sang
The separation between algorithm and adapter was unsharp at places. This was partly hidden by the fact, that the ISA-driver allowed just one instance and had all private data in static variables. This patch makes neccessary preparations to add a platform driver on top of the algorithm, while still supporting ISA. Note: Due to lack of hardware, the ISA-driver could not be tested except that it builds. Concerning the core struct i2c_algo_pca_data: - A private data field was added, all hardware dependant data may go here. Similar to other algorithms, now a pointer to this data is passed to the adapter's functions. In order to make as less changes as possible to the ISA-driver, it leaves the private data empty and still only uses its static variables. - A "reset_chip" function pointer was added; such a functionality must come from the adapter, not the algorithm. - use a variable "i2c_clock" instead of a function pointer "get_clock", allowing for write access to a default in case a wrong value was supplied. In the algorithm-file: - move "i2c-pca-algo.h" into "linux/i2c-algo-pca.h" - now using per_instance timeout values (i2c_adap->timeout) - error messages specify the device, not only the driver name - restructure initialization to easily support "i2c_add_numbered_adapter" - drop "retries" and "own" (i2c address) as they were unused (The state-machine for I2C-communication was not touched.) In the ISA-driver: - adapt to new algorithm Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2006-12-10i2c: Discard the i2c algo del_bus wrappersJean Delvare
They are all only calling i2c_del_adapter, so we may as well do it directly. Signed-off-by: Jean Delvare <khali@linux-fr.org>
2005-10-28[PATCH] i2c: Drop unused per-i2c-algorithm adapter maxJean Delvare
There are no more per-i2c-algorithm adapter max. Last time there were was in July 1999. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
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!