From: olof@lixom.net (Olof Johansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] ste_dma40 updates for 3.9
Date: Tue, 15 Jan 2013 11:14:50 -0800 [thread overview]
Message-ID: <20130115191450.GA28615@quad.lixom.net> (raw)
In-Reply-To: <CACRpkdZh=5FBDCuSFWYw8t-1Snm1xuS_EyVTUyQ-8kwVgjWuPA@mail.gmail.com>
On Tue, Jan 15, 2013 at 09:53:05AM +0100, Linus Walleij wrote:
> On Tue, Jan 15, 2013 at 7:48 AM, Olof Johansson <olof@lixom.net> wrote:
>
> > This series of patches only modify the ste_dma40 driver, there are no
> > corresponding changes under arch/arm that need to be coordinated or
> > considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
> > to only the driver.
> >
> > So is there a specific reason for why these shouldn't just go in
> > through the dmaengine tree?
>
> One reason would be if there are DMA bindings to device tree coming
> this merge window, as I'm told, and it implicates a lot of platform code
> changes on top of this as we adopt to it.
>
> But maybe this will be wholly confined to the DMAengine tree?
Changing platform code in the driver trees is asking for conflicts at
merge time and a grumpy Linus, I'd prefer to merge arch/arm/* through
arm-soc in that case.
Either way, this branch can be merged into dmaengine as a branch pull,
and if needed we can bring it in as a dependency on arm-soc. We would
need the same for the dmaengine DT bindings branch as a base. Of course,
that requires that Vinod doesn't rebase his branch and keeps the merge
intact. Vinod, is that compatible with your workflow?
-Olof
next prev parent reply other threads:[~2013-01-15 19:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 10:15 [GIT PULL] ste_dma40 updates for 3.9 Fabio Baltieri
2013-01-15 6:48 ` Olof Johansson
2013-01-15 8:53 ` Linus Walleij
2013-01-15 19:14 ` Olof Johansson [this message]
2013-01-20 14:07 ` Vinod Koul
2013-01-21 8:36 ` Fabio Baltieri
2013-01-15 8:55 ` Fabio Baltieri
2013-01-21 15:10 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130115191450.GA28615@quad.lixom.net \
--to=olof@lixom.net \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.