On Thu, May 12, 2016 at 10:56 AM, Will Deacon [off-list ref] wrote:

On Thu, May 12, 2016 at 12:29:02AM +0200, Rafael J. Wysocki wrote:

quoted

On Wed, May 11, 2016 at 11:30 PM, David Daney [off-list ref] wrote:

quoted

On 05/11/2016 02:22 PM, Rafael J. Wysocki wrote:

quoted

On Wed, May 11, 2016 at 11:08 PM, David Daney [off-list ref]
wrote:

quoted

On 05/11/2016 01:35 PM, Rafael J. Wysocki wrote:

quoted

On Wed, May 11, 2016 at 12:40 PM, Will Deacon [off-list ref]
wrote:

quoted

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! :)

quoted

quoted

quoted

quoted

quoted

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.

quoted

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