On Thu, May 12, 2016 at 10:56 AM, Will Deacon <will.deacon@xxxxxxx> wrote: > On Thu, May 12, 2016 at 12:29:02AM +0200, Rafael J. Wysocki wrote: >> On Wed, May 11, 2016 at 11:30 PM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx> wrote: >> > On 05/11/2016 02:22 PM, Rafael J. Wysocki wrote: >> >> On Wed, May 11, 2016 at 11:08 PM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx> >> >> wrote: >> >>> On 05/11/2016 01:35 PM, Rafael J. Wysocki wrote: >> >>>> On Wed, May 11, 2016 at 12:40 PM, Will Deacon <will.deacon@xxxxxxx> >> >>>> wrote: >> >>>>> On Wed, May 11, 2016 at 02:43:11AM +0200, Rafael J. Wysocki wrote: >> >>>>> There's also a dependency on the arm64 for-next/core branch, so I've >> >>>>> been >> >>>>> largely ignoring this as far as 4.6 is concerned and was planning to >> >>>>> take >> >>>>> a proper look for 4.7 once the upcoming merge window is out of the way. >> >>>> >> >>>> >> >>>> >> >>>> That would be 4.7 and 4.8 respectively I suppose? > > Argh, yes, of course! :) > >> >>>> >> >>>> Anyway, Catalin has ACKed all of them except for the [13/14], so >> >>>> technically I can apply [1-12/14] now and then [13-14/14] can be >> >>>> applied when they are ready. >> >>>> >> >>>> Do you think there will be any problems with merging [6-7/14] into 4.7 >> >>>> via the ACPI tree? >> >>>> >> >>> >> >>> I would defer to the arm64 maintainers for decisions about the arm64 >> >>> specific parts of the patch set. That said, many of the arm64 specific >> >>> patches depend on the arm64 for-next/core branch, so you would have to be >> >>> careful about merge ordering if you pull these in before the >> >>> for-next/core >> >>> branch is merged. >> >> >> >> >> >> Fair enough. I will wait for an update then. >> >> >> >>> Also FWIW, I plan on addressing Catalin's comments about 13/14 and >> >>> posting a >> >>> new version of the patch set in the next day or two. >> >> >> >> >> >> OK, but in that case it won't be considered for 4.7 (at least not by >> >> me), so I'd suggest sending it in the second half of the 4.7 merge >> >> window (or about that time). >> > >> > >> > To be candid, I would very much like for you to pull in as many of the >> > patches as you are comfortable with as soon as possible. >> > >> > I don't know where Will and Catalin stand on this, and their opinion is >> > obviously important, but getting 1-12/14 merged to v4.7 and deferring the >> > last two for v4.8 would simplify the whole process for me. The drawback is >> > carrying dead code around until the final parts are merged. >> >> That is not unheard of, however. >> >> OK, I'll try to put the [1-12/14] into my linux-next branch early next >> week and we'll see if that triggers any conflicts. > > I'd really much rather this waited until after the merge window. That's fine by me, so I guess my previous request for the next version to be sent by the end of the merge window applies. :-) > My understanding is that it's bad practice to put stuff into -next during the > merge window, Unless you want to push that stuff to Linus during the merge window in progress, that is. > and you'd end up having to send a pull based on a random > commit (the arm64 pull request?) in the second half. On top of that, this > series would get very little exposure in -next during that time. > > On the other hand, putting this into linux-next after the merge window > gives us time for testing, allows David to rework patch 13 (which is aiming > for 4.8 anyway iiuc) and avoids merge window churn. OK -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
