[PATCHv13 00/40] ARM: TI SoC clock DT conversion

[Mike Turquette]

Quoting Tony Lindgren (2014-01-15 09:13:23)
> * Mike Turquette <mturquette at linaro.org> [140114 19:52]:
> > > 
> > > These 40 patches apply very cleanly on top of clk-next with 2
> > > exceptions:
> > > 
> > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
> > > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
> > > on 3.13-rc1).
> > > 
> > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
> > > resolved correctly but would like verification.
> > > 
> > > I'd prefer to simply merge these patches into clk-next, which is the
> > > most straightforward route. Any ideas on how to handle the missing
> > > AM35xx dtsi data? It can always go as a separate fix after this stuff
> > > gets merged which, ironically, is how that file was created in the first
> > > place.
> 
> You could do something like this to take advantage of fast forward and
> not have to do a merge back from mainline:
> 
> $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi
> $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc
> $ git am am3517-clk-patch
> $ git checkout clk-next
> $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc

Tony,

That makes sense, but is there anything bad about doing that for a
branch you intend to send as a pull request? I don't see how any of the
commits get re-written or anything... I just wonder if there is some
subtlety that I am not accounting for that makes this approach bad for
sending to Linus.

Regards,
Mike

> 
> Regards,
> 
> Tony