25.07.2016, 10:22, "Wolfram Sang" <wsa@xxxxxxxxxxxxx>: >> > How do the other masters know that their channel is currently muxed >> > then? And what if two of them want to access two of your slaves at >> > the same time? >> >> In current implementation this I2C switch might be only switched from >> one side (via i2c command). From the MUX point of view, there is only >> one master (which may mux) and a number of slaves behind each channel. >> But on proto level IPMB requires to act as multi-master to receive >> answers from other intelligent nodes. To receive answer requesting >> node have to switch to slave mode after master write request. > > And how is guaranteed that one of the intelligent nodes behind the MUX > do no send requests on their own while their channel is not muxed? The MUX has been driven by high-level (logically) Master. RMC (Rack management controller) switches MUX to talk to slaves (BMC) of each node. There is guaranteed that BMC wouldn't act as Master (logically), but the line is muxed until timeout or answer received by RMC. BMCs are passive and only responds to requests. But regarding to the IPMB proto spec, every response have to be made as Master. -- 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
