[GIT PULL] Renesas ARM Based SoC DT Fixes for v4.8

[Simon Horman]

On Fri, Jul 22, 2016 at 09:30:58PM +0200, Arnd Bergmann wrote:
> On Friday, July 22, 2016 10:59:24 AM CEST Simon Horman wrote:
> > On Thu, Jul 21, 2016 at 02:41:52PM +0200, Arnd Bergmann wrote:
> > > On Monday, July 18, 2016 11:39:35 AM CEST Simon Horman wrote:
> > > > Renesas ARM Based SoC DT Fixes for v4.8
> > > > 
> > > > * Corrections to r8a7792
> > > > 
> > > 
> > > Merged into next/dt, thanks!
> > 
> > Thanks!
> > 
> > I have queued up another fix for v4.8 since sending the above to you.
> > This time it is an SoC (C-code) rather than a DT fix. I am wondering
> > if you could offer guidance on:
> > 
> > * If you would prefer me to split fixes out into separate (DT, SoC, ...)
> >   branches? If so is that until around rc1 when everything has been
> >   merged into the forthcoming release and thereafter you would prefer
> >   a single fixes branch?
> 
> I prefer a separate fixes branch. It's fine for all other branches
> to be based on top of this branch so you have a working baseline
> for testing.

Is some sort of minimal base for the fixes branch desired?
If should the base be a merge of all the tags you have pulled for v4.8?

Currently I have DT fixes and SoC fixes which depend on
respective tags that have been accepted for v4.8.

> > * What pace you would like me to send fixes. I guess it depends on
> >   where we are in the cycle. Currently I put the changes in next and
> >   send what I have about once a week (or not if there are none :).
> > 
> > Typically there are very few fixes. But as I already have 3 for v4.8,
> > including those in this pull request, I get the feeling a few more could
> > emerge before v4.8 is released.
> 
> I'd say don't wait longer than a week before forwarding bugfixes.
> If you find something urgent, just send that right away along with
> whatever less urgent patches you have accumulated.
> 
> It's possible we won't merge it right away as we might all be busy
> for a couple of days, but in the worst case that means you send
> another fixes pull request that is a superset before we have merged
> the first one.
> 
> 	Arnd
>