Re: [PATCH v5 0/9] Enhance the hv_vmbus driver to support hibernation

[Sasha Levin]

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