[GIT PULL v2] Reset controller API

[Shawn Guo]

On Thu, Apr 11, 2013 at 10:14:43AM -0700, Olof Johansson wrote:
> On Thu, Apr 11, 2013 at 02:37:09PM +0200, Philipp Zabel wrote:
> > Hi Olof,
> > 
> > Am Donnerstag, den 11.04.2013, 03:25 -0700 schrieb Olof Johansson:
> > > On Thu, Apr 11, 2013 at 3:20 AM, Olof Johansson <olof at lixom.net> wrote:
> > > > On Tue, Apr 09, 2013 at 10:19:34AM +0200, Philipp Zabel wrote:
> > > >> Hi Olof,
> > > >>
> > > >> I have added two fixes on top of the reset series at
> > > >> git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10.
> > > >> Could you pull them in together with the rest?
> > > >>
> > > >> The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
> > > >>
> > > >>   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
> > > >>
> > > >> are available in the git repository at:
> > > >>
> > > >>   git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
> > > >>
> > > >> for you to fetch changes up to fbdb93ecb869f02a5f8f145fa06a0984c415a7d4:
> > > >>
> > > >>   Documentation: gpio-reset.txt: Fix 'initially-in-reset' example (2013-04-09 09:55:00 +0200)
> > > >>
> > > >> They add a simple API for devices to request being reset by separate
> > > >> reset controller hardware and implement the reset signal device tree
> > > >> bindings proposed by Stephen Warren.
> > > >> The patches have been discussed on the linux-arm-kernel list under the topic
> > > >> "Reset controller API to reset IP modules on i.MX5 and i.MX6".
> > > >>
> > > >> ----------------------------------------------------------------
> > > >> Dan Carpenter (1):
> > > >>       reset: NULL deref on allocation failure
> > > >>
> > > >> Fabio Estevam (1):
> > > >>       Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
> > > >>
> > > >> Philipp Zabel (2):
> > > >>       reset: Add reset controller API
> > > >>       reset: Add driver for gpio-controlled reset pins
> > > >>
> > > >> Stephen Warren (1):
> > > >>       dt: describe base reset signal binding
> > > >
> > > > Hmm, I don't see an ack or reviewed-by on these subsystem bindings from
> > > > neither Rob nor Grant.
> > > >
> > > > Since it's a brand new subsystem binding, I'd like to see them ack it
> > > > before we pick it up.
> > > 
> > > Sigh. Ok, so I now stumbled across the Ack from Rob that you didn't
> > > pick up. Don't do it like that again, please. If Shawn prematurely
> > > bases his code on top of unacked patches, then that's his problem, not
> > > yours.
> > 
> > Sorry I didn't notice that Rob's ack didn't have you in Cc. So shall I
> > leave the dt binding patch untouched this time? I'll take note of this
> > for the future.
> 
> See below.
> 
> > > The problem still remains though, since the gpio-reset binding hasn't
> > > seen an ack on the list, as far as I can tell. And I'll have a comment
> > > on that as well in a minute, see separate reply on that patch.
> > 
> > Ok. What would you have me do now? I could revert the gpio-reset patch
> > (possibly asking Shawn to pull that, too), and have it do another round
> > on the list instead. Or I could address your comments with a relative
> > patch, and put that on top.
> 
> This is a case where rebase is fine, as far as I am concerned. Just tell
> Shawn to also rebase his dependent code accordingly. That way you can
> add Rob's ack too.
> 
> Once the bindings have been ironed out you can add it back, but that's looking
> like 3.11 material now.

Just to be clear, you are asking Philipp to move patch "reset: Add
driver for gpio-controlled reset pins" out (leave it for 3.11), and add
Rob's ACK on patch "dt: describe base reset signal binding", and then
resend the pull request. Is it correct?

Shawn