Hi Wolfram and Peter,
I will give my opinion about the path chosen although it should be
taken lightly.

I can see that hardware guys missed the software guys again on the
development path, but since this happens more often than not, I would
say it seems OK to have support for this as long as it does not make
more complex (longer) standard i2c transfers. I would support to have
additional mutex before mux as that will make less chance that someone
forgets to lock mutex before mux and proposed solution seems valid.

Regards,
Crt

On 5 January 2016 at 19:48, Wolfram Sang [off-list ref] wrote:

Peter,

quoted

PS. needs a bunch of testing, I do not have access to all the involved hw

First of all, thanks for diving into this topic and the huge effort you
apparently have put into it.

It is obviously a quite intrusive series, so it needs careful review.
TBH, I can't really tell when I have the bandwidth to do that, so I hope
other people will step up. And yes, it needs serious testing.

To all: Although I appreciate any review support, I'd think the first
thing to be done should be a very high level review - is this series
worth the huge update? Is the path chosen proper? Stuff like this. I'd
appreciate Acks or Revs for that. Stuff like fixing checkpatch warnings
and other minor stuff should come later.

Thanks,

   Wolfram