lkml.org 
[lkml]   [2014]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/10] pinctrl: mvebu: remove hard-coded addresses from Dove pinctrl
    On Wed, Feb 26, 2014 at 10:43:45AM +0100, Linus Walleij wrote:
    > On Wed, Feb 26, 2014 at 1:09 AM, Jason Cooper <jason@lakedaemon.net> wrote:
    >
    > > Sebastian has now re-organized the branches as I asked, and I confirmed
    > > that the final result is the exact same as mine (diff is null).
    >
    > Okay!
    >
    > > Usually when I submit pull requests to arm-soc, they like to see the
    > > branches. That way if there is an error in one of them, they just drop
    > > the one branch and the others remain.
    > >
    > > Would you like them the same way? If so, I'll send the pulls to you
    > > tomorrow.
    >
    > Send me one big branch with everything on it.

    Sure.

    > Actually, I'd prefer to pull it in, rebase and sign off each patch
    > individually in my tree if that is not causing you problems.

    Actually, that would mess us up pretty badly. :( One of the reasons we
    take the effort to base off of -rc1 and create stable topic branches is
    so that the commit IDs don't change. This way, all the patches needed
    to boot the new mvebu SoCs (code intended for v3.15) can be boot tested
    from the mvebu/for-next branch, which is merge-tested and randconfig
    tested in linux-next. This all happens _before_ the merge window for
    v3.15.

    There have been huge benefits since we started doing this. In fact,
    just yesterday I committed three patches to fix issues discovered as a
    result of this process:

    edd9d3cffc90 watchdog: orion_wdt: Use %pa to print 'phys_addr_t'
    1b82af4f1749 ARM: kirkwood: select dtbs based on SoC
    a02dd0271d01 ARM: mvebu: select dtbs from MACH_ARMADA_*

    The first was discovered by Olof's autobuilder, and the last two were
    discovered by Kevin's boot farm.

    If you rebase the branch, I'll have to drop it from our for-next tree to
    prevent conflicts in linux-next with your -next branch. Which means no
    one will be able to boot test the new SoCs without going through a lot
    of hunting to re-collect all the branches.

    The advantage of having mvebu/for-next in addition to linux-next is that
    should there be a boot failure, we can quickly determine whether it is a
    result of the mvebu code (mvebu/for-next fails) or something outside of
    mvebu (only linux-next fails).

    By keeping the commit IDs the same, the same branch can be in multiple
    trees all getting merged into linux-next. Currently, mvebu does this
    with arm-soc, clk, and irqchip. In those cases, those maintainers are
    the ones who send the pull requests to Linus, not us.

    > That way it is visible that the patches were funneled through pin
    > control.

    I'm a little confused by this. Once you merge the branch into one of
    yours, that merge commit is a part of the history. In fact, the branch
    is still intact for eternity. So by merging the branch, adding other
    patches, and signing the tip of the result, it should be clear it came
    through pinctrl, no?

    thx,

    Jason.


    \
     
     \ /
      Last update: 2014-02-26 16:41    [W:2.895 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site