[PATCH 1/6] staging: nvec: convert to devm_ functions

Marc Dietrich marvin24 at gmx.de
Wed Jun 13 09:05:32 UTC 2012


Am Dienstag, 12. Juni 2012, 13:55:19 schrieb Dan Carpenter:
> On Tue, Jun 12, 2012 at 12:39:17PM +0200, Marc Dietrich wrote:
> > This patch cleanups the nvec and its childs by replacing calls to
> > resource allocations by their devm_* equivalents.
> > 
> > Signed-off-by: Marc Dietrich <marvin24 at gmx.de>
> > ---
> > 
> > Ok, this is directly against 3.5-rc2. All other patches in this series 
apply 
> > cleanly and can be reused.
> > 
> > To speed things up, I'm going to rebase Adnan patch against this series 
and 
> > resend it later with proper From: line. There is also another
> > patch pending which replaces clk_enable/disable by clk_prepare_* which 
needs 
> > rebasing. I'm going to rebase and submit this too. Hope this is ok.
> > 
> 
> No, that doesn't help.  This stuff isn't going into 3.5, it has to
> wait until 3.6.  Patch against today's linux-next or staging-next.

This starts to get confusing: patches from different people to be merged to 
different branches with comments from different reviewers with conflicting 
content (which branch to base upon).

IMHO, all patches are targeted at 3.6, this is why I originally based mine on 
linux-next. In fact, this doesn't matter as both branches are currently equal 
when it comes to nvec.

> Also this patch is line wrapped so it doesn't apply.

Sorry for that, I'll send a new version as a reply to the older one.

> > @@ -737,15 +736,15 @@ static int __devinit tegra_nvec_probe(struct 
> > platform_device *pdev)
> 
> Thanks for taking care of Adnan's patch.  The commentry on that
> thread wasn't about the patch.  Everyone was fine with Adnan's
> patch.

Maybe I took *too* much care of it. What is the policy here? Just don't care 
of what others are sending and base your own patches upon a certain branch tag 
(e.g. 3.5-rc2) and let Greg resolve the conflicts? Or apply some kind of 
"serialization" following first come first serve principle? I'm kinda lost 
here.

Marc






More information about the devel mailing list