From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 0/3] arm: mvebu: fix resource leak
Date: Tue, 27 Aug 2013 11:27:46 +0800 [thread overview]
Message-ID: <20130827112746.2e5abc73@xhacker> (raw)
In-Reply-To: <20130827032237.GA19598@titan.lakedaemon.net>
Dear Jason,
On Mon, 26 Aug 2013 20:22:37 -0700
Jason Cooper <jason@lakedaemon.net> wrote:
> On Tue, Aug 27, 2013 at 11:01:20AM +0800, Jisheng Zhang wrote:
> > Dear Jason,
> >
> > On Mon, 26 Aug 2013 13:45:23 -0700
> > Jason Cooper <jason@lakedaemon.net> wrote:
> >
> > > On Mon, Aug 26, 2013 at 07:36:55PM +0800, Jisheng Zhang wrote:
> > > > These patches try to fix resource leak by adding missing
> > > > of_node_put(), iounmap or using devm_ioremap_resource() if available.
> > > >
> > > > v4:
> > > > - re-generate since Ezequiel's patches add DT support to the
> > > > mvebu-mbus driver
> > >
> > > grrr. I hate to ask this, but can you please rebase patches 1 and 2
> > > against mvebu/fixes-non-critical? No need to add back in the mvebu-mbus
> > > hunk.
> >
> > patch 1 also fixes one similar trivial issue introduced since
> > 994c8c94b419e "ARM: mvebu: Remove the harcoded BootROM window allocation"
> > in linux-next tree
> >
> > patch 2 is updated to fix similar trivial issue introduce since
> > 6839cfa82f99 "bus: mvebu-mbus: Introduce device tree binding"
> >
> > These two commits aren't included in mvebu/fixes-non-criticial yet. Could
> > you please give suggestion?
>
> Yes, that's correct. We prefer to have patch submitters base off of a
> mainline tag (eg v3.11-rc7). conflicts between patchsets are then
> caught and resolved when branches are merged. If done correctly, the
> merge resolution should be obvious in most cases.
>
> The upstream maintainers _prefer_ to see those conflicts because it
> gives them a better sense of who is tinkering in the same code-paths.
>
> Trying to base patches off of disparate branches in order to
> 'pre-resolve' those conflicts creates unnecessary dependencies and
> non-obvious merge-resolutions.
>
> In this case I asked you base off of mvebu/fixes-non-critical because
> that is where I will be applying them for queueing to arm-soc. You
> could also base off of v3.11-rc7, there's nothing in
> mvebu/fixes-non-critical that should conflict with your changes.
>
Got it. Thanks very much for your excellent explanation.
Will do and send out patches latter.
Best Regards,
Jisheng
prev parent reply other threads:[~2013-08-27 3:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-26 11:36 [PATCH v4 0/3] arm: mvebu: fix resource leak Jisheng Zhang
2013-08-26 11:36 ` [PATCH v4 1/3] arm: mvebu: add missing of_node_put() to fix reference leak Jisheng Zhang
2013-08-26 11:36 ` [PATCH v4 2/3] bus: " Jisheng Zhang
2013-08-26 11:36 ` [PATCH v4 3/3] pinctrl: mvebu: Convert to use devm_ioremap_resource Jisheng Zhang
2013-08-26 20:46 ` Jason Cooper
2013-08-26 20:45 ` [PATCH v4 0/3] arm: mvebu: fix resource leak Jason Cooper
2013-08-27 3:01 ` Jisheng Zhang
2013-08-27 3:22 ` Jason Cooper
2013-08-27 3:27 ` Jisheng Zhang [this message]
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=20130827112746.2e5abc73@xhacker \
--to=jszhang@marvell.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).