Re: [PATCH v3 0/8] i2c mux cleanup and locking update

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]


> 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?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]