On Wed, Jun 13, 2012 at 11:05:32AM +0200, Marc Dietrich wrote: > 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@xxxxxx> > > > --- > > > > > > 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). > Yep. Different trees have their own rules, that's true. But probably it's most common to work against linux-next. For staging there is too much churn so everything is done against linux-next. > 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. Yes. It is first come first serve. Which ever patch gets sent to list first gets merged first. If your patch doesn't apply when Greg tries to apply it then you have to redo it against staging-next (or the next day's linux-next release). You're absolutely not under any obligation to redo Adnan's patches, just send him an email to resend it to the list if you want. regards, dan carpenter _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
