You are welcome. In my implementation in PCA954x I did the following things that I would like to highlight: 1. handle slave register and store i2c_client data to the internal array (length equal to number of channels). First obstacle – get the right offset in the array (channel number). It's better to expose "chan_id" field from i2c_mux_priv as a public function. I did a hack during init by writing down first muxc->adapter's number ("nr" field store in private adap_off). 2. during handling of select_chan I'm trying to register new i2c dummy device with newly selected slave addr corresponding to the channel number (if it has a slave). This is the second problem – after I've registered dummy device with some slave address, I'm not able to register slave devices for other mux'ed busses with the same slave addr. In other words, I have to populate all the slave devices (with the same slave addr) right before I'm going to use the bus first time. 3. registering and/or unregister first (if applicable) slave device on the parent bus adapter. This is the third obstacle. While the bus is already locked, calling generic i2c_slave_{register,unregister} lead to the deadlock. I did it directly via the reg_slave/unreg_slave calls of appropriate data structure. Notes: Slave works only with keeping channel selected while generic i2c-mux logic is to deselect channel after each i2c transfers. 25.07.2016, 12:41, "Wolfram Sang" <wsa@xxxxxxxxxxxxx>: >> There is no way to switch mux and request to BMC #2. Logically, this shouldn't >> happen too. > > I see. I think I have the big picture now, thanks for the heads up. > > However, I am not sure what recommendations I can give to you. I'd start > with adding reg_slave to the muxed adapters and then try to reconfigure > the real adapter when the mux switches (I assume you did that already). > But I don't have the bandwidth to dive into that and see what gory > details come up. Maybe Peter Rosin has something to add, though? -- 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