On 2016-03-05 19:29, Wolfram Sang wrote: > >> 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.) My code wouldn't be worth much if I didn't offer to look after it myself. On the other hand, I am also reluctant to be the go-to person for all things i2c-mux, as I don't have a clear picture of how much work it's going to be. My offer is going to be this, I'll look after any unforeseen future problems caused by this rework, and I can be the i2c-mux maintainer. But if being the i2c-mux maintainer turns out to be a huge time-sink, there is no way I can stay on in the long run. But I guess that is the same for any maintainer (whose job description does not explicitly include being maintainer). > 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. Yes, sounds good. One of the reasons for doing things right (or at least trying to) is to have more people look at the work. *I* think it's good, but more eyes can't hurt. > 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? I had a brief look, and I can't see anything in the demux that's affected by the mux update. The main commonality of the demux and the preexisting muxes seems to be that the name includes "mux" and that it is all about i2c. Agreed? In short, I see no problems. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
