On Sunday, February 17, 2013 07:31:37 AM Liu, Jinsong wrote: > Rafael J. Wysocki wrote: > > On Saturday, February 16, 2013 01:52:00 AM Stephen Rothwell wrote: > >> Hi Rafael, > > > > Hi, > > > >> On Fri, 15 Feb 2013 15:53:34 +0100 "Rafael J. Wysocki" <rjw@xxxxxxx> > >> wrote: > >>> > >>> On Saturday, February 16, 2013 12:50:14 AM Stephen Rothwell wrote: > >>>> > >>>> On Fri, 15 Feb 2013 08:26:24 -0500 Konrad Rzeszutek Wilk > >>>> <konrad.wilk@xxxxxxxxxx> wrote: > >>>>> > >>>>> Thank you. I keep on forgetting - but would it be OK for me to > >>>>> take this patch in my tree? Or should I not since this is a new > >>>>> functionality that Rafael is going to introduce in v3.9? > >>>> > >>>> It is an API change in the pm tree that is not yet in Linus' tree. > >>>> > >>>>> And if so, perhaps I should tack it on in my tree, once Rafael > >>>>> does a git pull to Linus? Or just point Linus to this git commit? > >>>> > >>>> You should point Linus at this patch if the pm tree is merged > >>>> first, or > >>>> Rafael should do the same if the reverse happens. > >>> > >>> Alternatively, Konrad can pull the acpi-scan branch containing the > >>> changes in question from my tree into his tree and rebase the new > >>> material on top of that. > >> > >> Or pull the acpi-scan branch into his tree and use my conflict > >> resolution in the resulting merge thus requiring no rebasing. > >> However, Linus likes to see such interactions, so it can be left up > >> to when the latter of the two tress is merged by Linus. > > > > Well, I'm afraid this won't be sufficient this time, because of this > > commit in my tree (which is not on the acpi-scan branch): > > > > commit 3757b94802fb65d8f696597a74053cf21738da0b > > Author: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > Date: Wed Feb 13 14:36:47 2013 +0100 > > > > ACPI / hotplug: Fix concurrency issues and memory leaks > > > > after which acpi_bus_scan() and acpi_bus_trim() have to be run under > > acpi_scan_lock (new in my tree as well). > > Yes, we noticed that and only need minor updates at xen side, will send out > 2 xen patches later accordingly, for cleanup and adding lock. Thanks, but those new changes will only make sense after merging the Xen tree with the PM tree. Why don't we queue them up for merging later after both the Xen and PM trees have been pulled from? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
