[PATCH][RESEND] video: hyperv_fb: Fix hibernation for the deferred IO feature

fb_deferred_io_work() can access the vmbus ringbuffer by calling
fbdefio->deferred_io() -> synthvid_deferred_io() -> synthvid_update().

Because the vmbus ringbuffer is inaccessible between hvfb_suspend()
and hvfb_resume(), we must cancel info->deferred_work before calling
vmbus_close() and then reschedule it after we reopen the channel
in hvfb_resume().

Fixes: a4ddb11d297e ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
Fixes: 824946a8b6fb ("video: hyperv_fb: Add the support of hibernation")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Wei Hu <redacted>
---

This is a RESEND of https://lkml.org/lkml/2019/11/20/73 .

The only change is the addition of Wei's Review-ed-by.

Please review.

If it looks good, Sasha Levin, can you please pick it up via the
hyperv/linux.git tree, as you did last time for this driver?


 drivers/video/fbdev/hyperv_fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 4cd27e5172a1..08bc0dfb5ce7 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c

@@ -1194,6 +1194,7 @@ static int hvfb_suspend(struct hv_device *hdev)
 	fb_set_suspend(info, 1);
 
 	cancel_delayed_work_sync(&par->dwork);
+	cancel_delayed_work_sync(&info->deferred_work);
 
 	par->update_saved = par->update;
 	par->update = false;

@@ -1227,6 +1228,7 @@ static int hvfb_resume(struct hv_device *hdev)
 	par->fb_ready = true;
 	par->update = par->update_saved;
 
+	schedule_delayed_work(&info->deferred_work, info->fbdefio->delay);
 	schedule_delayed_work(&par->dwork, HVFB_UPDATE_DELAY);
 
 	/* 0 means do resume */

-- 
2.19.1

On Mon, Jan 06, 2020 at 02:41:51PM -0800, Dexuan Cui wrote:

fb_deferred_io_work() can access the vmbus ringbuffer by calling
fbdefio->deferred_io() -> synthvid_deferred_io() -> synthvid_update().

Because the vmbus ringbuffer is inaccessible between hvfb_suspend()
and hvfb_resume(), we must cancel info->deferred_work before calling
vmbus_close() and then reschedule it after we reopen the channel
in hvfb_resume().

Fixes: a4ddb11d297e ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
Fixes: 824946a8b6fb ("video: hyperv_fb: Add the support of hibernation")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Wei Hu <redacted>
---

This is a RESEND of https://lkml.org/lkml/2019/11/20/73 .

The only change is the addition of Wei's Review-ed-by.

Please review.

If it looks good, Sasha Levin, can you please pick it up via the
hyperv/linux.git tree, as you did last time for this driver?

Like with the input driver, if the relevant maintainers here are okay
with this type of patches going through the hyperv tree I'll be happy to
do it, otherwise I need an explicit ack from them on this patch.

-- 
Thanks,
Sasha

On 1/11/20 5:29 PM, Sasha Levin wrote:

On Mon, Jan 06, 2020 at 02:41:51PM -0800, Dexuan Cui wrote:

quoted

fb_deferred_io_work() can access the vmbus ringbuffer by calling
fbdefio->deferred_io() -> synthvid_deferred_io() -> synthvid_update().

Because the vmbus ringbuffer is inaccessible between hvfb_suspend()
and hvfb_resume(), we must cancel info->deferred_work before calling
vmbus_close() and then reschedule it after we reopen the channel
in hvfb_resume().

Fixes: a4ddb11d297e ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
Fixes: 824946a8b6fb ("video: hyperv_fb: Add the support of hibernation")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Wei Hu <redacted>
---

This is a RESEND of https://protect2.fireeye.com/url?k©db9902-f41598d1-a9da124d-000babff317b-c1ee475745c278a5&u=https://lkml.org/lkml/2019/11/20/73 .

The only change is the addition of Wei's Review-ed-by.

Please review.

If it looks good, Sasha Levin, can you please pick it up via the
hyperv/linux.git tree, as you did last time for this driver?

Like with the input driver, if the relevant maintainers here are okay
with this type of patches going through the hyperv tree I'll be happy to
do it, otherwise I need an explicit ack from them on this patch.

Yes, I'm fine with hyperv_fb driver patches going through hyperv tree.

Acked-by: Bartlomiej Zolnierkiewicz <redacted>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics