[GIT PULL] Allwinner DT changes for 4.4, round 3

Stephen Boyd sboyd at codeaurora.org
Mon Nov 9 13:14:13 PST 2015

On 11/08, Maxime Ripard wrote:
> On Mon, Nov 02, 2015 at 11:19:23AM -0800, Stephen Boyd wrote:
> > > >> I've merged this in now. Note that this has resulted in a tree that won't
> > > >> misect cleanly, since having the clk contents merged instead of used as a base
> > > >> for the dt branch means that you could end up in a bisect state that has the DT
> > > >> branch but not the clk branch.
> > > >
> > > > Even if it has been merged before the DT patches have been applied?
> > > > That's not really what I'd expect from bisect :/
> > > 
> > > Yeah, due to the way bisect works, the only way to guarantee
> > > bisectability is if you base the DT branch on top of the clk branch
> > > when you build it. Otherwise the bisect can come down the path of only
> > > having the DT contents not the clk contents.
> > 
> > Why can't the dts changes be applied directly on top of the
> > branch that's in the clk tree and then sent off to arm-soc? The
> > git merge && git commit technique also works, but it introduces
> > an unnecessary merge commit into the history.
> Wouldn't that mean that you have to rebase your whole DT branch
> whenever a single patch introduces a dependency on some clock patch?

That depends on whether or not the single patch depends on the
other patches in the "DT" branch. If it did, then do the merge
and apply the single patch on top. But if doesn't, maybe it's
something like new SoC support that needs a binding header, I
would make a second DT branch that points at the branch in the
clk tree and then apply the dt patch directly on top.

Of course, this is just one way to do it. I'm mostly trying to
avoid unnecessary merges, but sometimes merges are unavoidable.
The most important thing is to maintain bisectability and to make
it clear why merges from other trees are done by putting some
sort of reason in the commit text of the merge.

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

More information about the linux-arm-kernel mailing list