Perhaps it's one to let sit into at least the next cycle (and get some testing
on those media devices if we can) but, whilst it is fiddly the gains seen in
individual drivers (like the example Peter put in response to the V4 series)
make it look worthwhile to me.  Also, whilst the invensense part is plain odd
in many ways, the case Peter had looks rather more normal.

At the end of the day, sometimes fiddly problems need fiddly code. 
(says a guy who doesn't have to maintain it!)

It certainly helps that Peter has done a thorough job, broken the patches
up cleanly and provided clean descriptions of what he is doing.

Yes, Peter has done a great job so far and the latest results were very
convincing (fixing the invensense issue and the savings for rtl2832).

And yes, I am reluctant to maintain this code alone, so my question
would be:

Peter, are you interested in becoming the i2c-mux maintainer and look
after the code even after it was merged? (From "you reviewing patches and
me picking them up" to "you have your own branch which I pull", we can
discuss the best workflow.)

If that would be the case, I have the same idea like Jonathan: Give it
another cycle for more review & test and aim for the 4.7 merge window.

I have to admit that I still haven't done a more thorough review, so I
can't say if I see a show-stopper in this series. Yet, even if so I am
positive it can be sorted out. Oh, and we should call for people with
special experience in locking.

What do people think?

Regards,

   Wolfram

PS: Peter, have you seen my demuxer driver in my for-next branch? I hope
it won't spoil your design?