On Fri, Sep 06, 2019 at 10:45:31PM +0000, Dexuan Cui wrote:
From: Sasha Levin <sashal@xxxxxxxxxx>
Sent: Friday, September 6, 2019 1:03 PM
On Thu, Sep 05, 2019 at 11:01:14PM +0000, Dexuan Cui wrote:
>This patchset (consisting of 9 patches) was part of the v4 patchset (consisting
>of 12 patches):
>
>The other 3 patches in v4 are posted in another patchset, which will go
>through the tip.git tree.
>
>All the 9 patches here are now rebased to the hyperv tree's hyperv-next
branch, and all the 9 patches have Michael Kelley's Signed-off-by's.
>
>Please review.
Given that these two series depend on each other, I'd much prefer for
them to go through one tree.
Hi Sasha,
Yeah, that would be ideal. The problem here is: the other patchset conflicts
with the existing patches in the tip.git tree's timers/core branch, so IMO
the 3 patches have to go through the tip tree:
[PATCH v5 1/3] x86/hyper-v: Suspend/resume the hypercall page for hibernation
[PATCH v5 2/3] x86/hyper-v: Implement hv_is_hibernation_supported()
[PATCH v5 3/3] clocksource/drivers: Suspend/resume Hyper-V clocksource for hibernation
But, I may be wrong, and I'm going to see if a scenario such as this
make sense. I've queued this one to the hyperv-next, but I'll wait for
the x86 folks to send their pull request to Linus first before I do it
for these patches.
Actually IMHO you don't need to wait, because there is not a build
dependency, so either patchset can go into the Linus's tree first.
It'll build, sure. But did anyone actually test one without the other?
What happens if Thomas doesn't send his batch at all during the merge
window?
--
Thanks,
Sasha
