On Thu, 2009-10-29 at 15:43 +0100, Jean Delvare wrote: > Hi Stephen, > > On Mon, 26 Oct 2009 13:37:57 +1100, Stephen Rothwell wrote: > > Today's linux-next merge of the net tree got a conflict in > > drivers/net/sfc/sfe4001.c between commit > > 3f7c0648f727a6d5baf6117653e4001dc877b90b ("i2c: Prevent priority > > inversion on top of bus lock") from the i2c tree and commit > > c9597d4f89565b6562bd3026adbe6eac6c317f47 ("sfc: Merge sfe4001.c into > > falcon_boards.c") from the net tree. > > > > I have applied the following merge fixup patch (after removing > > drivers/net/sfc/sfe4001.c) and can carry it as necessary. > > Thanks for fixing it. The core problem here IMHO is that the sfc > network driver touches i2c internals which it would rather leave alone. I'm just a little proud of having the idea that we could avoid using an I/O-expander on this board, but yes, the software side of this multiplexing is a hack. > This is the only driver I know of which does this. > > I can think of 3 different ways to address the issue. > > Method #1: add a public API to grab/release an I2C segment. > > void i2c_adapter_lock(struct i2c_adapter *adapter) > { > rt_mutex_lock(&adapter->bus_lock); > } > > void i2c_adapter_unlock(struct i2c_adapter *adapter) > { > rt_mutex_unlock(&adapter->bus_lock); > } [...] > I'm not really sure if I have a preference yet, so please speak up if > you do. Indirect lock operations are a recipe for deadlock, and there doesn't seem to be any other user for this, so method 1 seems best. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html