> 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:
signature.asc
Description: PGP signature
