From 6ef91fcca8a8ba3df9810a4cc6cd6a9d3f21bf45 Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Wed, 4 May 2016 22:15:29 +0200 Subject: i2c: mux: relax locking of the top i2c adapter during mux-locked muxing With a i2c topology like the following GPIO ---| ------ BAT1 | v / I2C -----+----------+---- MUX | \ EEPROM ------ BAT2 there is a locking problem with the GPIO controller since it is a client on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1) will lock the whole i2c bus prior to attempting to switch the mux to the correct i2c segment. In the above case, the GPIO device is an I/O expander with an i2c interface, and since the GPIO subsystem knows nothing (and rightfully so) about the lockless needs of the i2c mux code, this results in a deadlock when the GPIO driver issues i2c transfers to modify the mux. So, observing that while it is needed to have the i2c bus locked during the actual MUX update in order to avoid random garbage on the slave side, it is not strictly a must to have it locked over the whole sequence of a full select-transfer-deselect mux client operation. The mux itself needs to be locked, so transfers to clients behind the mux are serialized, and the mux needs to be stable during all i2c traffic (otherwise individual mux slave segments might see garbage, or worse). Introduce this new locking concept as "mux-locked" muxes, and call the pre-existing mux locking scheme "parent-locked". Modify the i2c mux locking so that muxes that are "mux-locked" locks only the muxes on the parent adapter instead of the whole i2c bus when there is a transfer to the slave side of the mux. This lock serializes transfers to the slave side of the muxes on the parent adapter. Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved gpio/pinctrl devices have a parent that is an i2c adapter in the same adapter tree that is muxed, and request a "mux-locked mux" if that is the case. Modify the select-transfer-deselect code for "mux-locked" muxes so that each of the select-transfer-deselect ops locks the mux parent adapter individually. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang --- include/linux/i2c-mux.h | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'include/linux/i2c-mux.h') diff --git a/include/linux/i2c-mux.h b/include/linux/i2c-mux.h index 2fa93fe1345e..d4c1d12f900d 100644 --- a/include/linux/i2c-mux.h +++ b/include/linux/i2c-mux.h @@ -27,9 +27,12 @@ #ifdef __KERNEL__ +#include + struct i2c_mux_core { struct i2c_adapter *parent; struct device *dev; + bool mux_locked; void *priv; @@ -47,11 +50,16 @@ struct i2c_mux_core *i2c_mux_alloc(struct i2c_adapter *parent, int (*select)(struct i2c_mux_core *, u32), int (*deselect)(struct i2c_mux_core *, u32)); +/* flags for i2c_mux_alloc */ +#define I2C_MUX_LOCKED BIT(0) + static inline void *i2c_mux_priv(struct i2c_mux_core *muxc) { return muxc->priv; } +struct i2c_adapter *i2c_root_adapter(struct device *dev); + /* * Called to create an i2c bus on a multiplexed bus segment. * The chan_id parameter is passed to the select and deselect -- cgit v1.2.3