On 2020-05-15 11:20, Wolfram Sang wrote: > >> So this does not really solve my problem - even if we do get the lock >> by calling select(), we will simply release it as soon as our >> i2c_transfer() is finished (and will let the other master take it, >> breaking atomicity of the two operations I need to perform on target >> device) and this is exactly what I need to avoid. > > I was assuming that once you have the lock from the arbitrator you can > be sure that the other master is not active and, thus, you maybe don't > need to read the status register at all? But I am probably wrong here. You are right in that when you have the lock from the arbtrator, you lock the other master(s) out, but the issue here is that the mux code releases the arbitrator lock after each xfer. Krzysztof needs to do two xfers with the arbitrator lock held over both so that another master cannot sneak in and change the world view. Cheers, Peter