[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160305182934.GA1394@katana>
Date: Sat, 5 Mar 2016 19:29:35 +0100
From: Wolfram Sang <wsa@...-dreams.de>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Peter Rosin <peda@...ator.liu.se>, Peter Rosin <peda@...ntia.se>,
Peter Korsgaard <peter.korsgaard@...co.com>,
Guenter Roeck <linux@...ck-us.net>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald <pmeerw@...erw.net>,
Antti Palosaari <crope@....fi>,
Mauro Carvalho Chehab <mchehab@....samsung.com>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
Grant Likely <grant.likely@...aro.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Adriana Reus <adriana.reus@...el.com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Hans Verkuil <hans.verkuil@...co.com>,
Nicholas Mc Guire <hofrat@...dl.org>,
Olli Salonen <olli.salonen@....fi>, linux-i2c@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
linux-media@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 0/8] i2c mux cleanup and locking update
> 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?
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists