Add suspend() and resume() functions so the Hyper-V virtual keyboard
can participate in VM hibernation.
Note that the keyboard is a "wakeup" device that could abort an in-progress
hibernation if there is keyboard event. No attempt is made to suppress this
behavior. If desired, a sysadmin can disable the keyboard as a wakeup device
using standard mechanisms such as:
echo disabled > /sys/bus/vmbus/drivers/hyperv_keyboard/XXX/power/wakeup
(where XXX is the device's GUID)
Reviewed-by: Michael Kelley <[email protected]>
Signed-off-by: Dexuan Cui <[email protected]>
---
This is a RESEND of https://lkml.org/lkml/2019/11/24/115 .
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/input/serio/hyperv-keyboard.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/input/serio/hyperv-keyboard.c b/drivers/input/serio/hyperv-keyboard.c
index e486a8a74c40..df4e9f6f4529 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -259,6 +259,8 @@ static int hv_kbd_connect_to_vsp(struct hv_device *hv_dev)
u32 proto_status;
int error;
+ reinit_completion(&kbd_dev->wait_event);
+
request = &kbd_dev->protocol_req;
memset(request, 0, sizeof(struct synth_kbd_protocol_request));
request->header.type = __cpu_to_le32(SYNTH_KBD_PROTOCOL_REQUEST);
@@ -380,6 +382,29 @@ static int hv_kbd_remove(struct hv_device *hv_dev)
return 0;
}
+static int hv_kbd_suspend(struct hv_device *hv_dev)
+{
+ vmbus_close(hv_dev->channel);
+
+ return 0;
+}
+
+static int hv_kbd_resume(struct hv_device *hv_dev)
+{
+ int ret;
+
+ ret = vmbus_open(hv_dev->channel,
+ KBD_VSC_SEND_RING_BUFFER_SIZE,
+ KBD_VSC_RECV_RING_BUFFER_SIZE,
+ NULL, 0,
+ hv_kbd_on_channel_callback,
+ hv_dev);
+ if (ret == 0)
+ ret = hv_kbd_connect_to_vsp(hv_dev);
+
+ return ret;
+}
+
static const struct hv_vmbus_device_id id_table[] = {
/* Keyboard guid */
{ HV_KBD_GUID, },
@@ -393,6 +418,8 @@ static struct hv_driver hv_kbd_drv = {
.id_table = id_table,
.probe = hv_kbd_probe,
.remove = hv_kbd_remove,
+ .suspend = hv_kbd_suspend,
+ .resume = hv_kbd_resume,
.driver = {
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
--
2.19.1
On Mon, Jan 06, 2020 at 02:40:44PM -0800, Dexuan Cui wrote:
>Add suspend() and resume() functions so the Hyper-V virtual keyboard
>can participate in VM hibernation.
>
>Note that the keyboard is a "wakeup" device that could abort an in-progress
>hibernation if there is keyboard event. No attempt is made to suppress this
>behavior. If desired, a sysadmin can disable the keyboard as a wakeup device
>using standard mechanisms such as:
>
>echo disabled > /sys/bus/vmbus/drivers/hyperv_keyboard/XXX/power/wakeup
>(where XXX is the device's GUID)
>
>Reviewed-by: Michael Kelley <[email protected]>
>Signed-off-by: Dexuan Cui <[email protected]>
>---
>
>This is a RESEND of https://lkml.org/lkml/2019/11/24/115 .
>
>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?
This will need an ack from the input driver maintainers, unless they
want to give a blanket ack to this type of patches.
--
Thanks,
Sasha
> From: Sasha Levin <[email protected]>
> Sent: Saturday, January 11, 2020 8:27 AM
> To: Dexuan Cui <[email protected]>
> Cc: KY Srinivasan <[email protected]>; Haiyang Zhang
> <[email protected]>; Stephen Hemminger
> <[email protected]>; [email protected];
> [email protected]; [email protected];
> [email protected]; Michael Kelley <[email protected]>;
> Sasha Levin <[email protected]>
> Subject: Re: [PATCH][RESEND] Input: hyperv-keyboard: Add the support of
> hibernation
>
> On Mon, Jan 06, 2020 at 02:40:44PM -0800, Dexuan Cui wrote:
> >Add suspend() and resume() functions so the Hyper-V virtual keyboard
> >can participate in VM hibernation.
> >
> >Note that the keyboard is a "wakeup" device that could abort an in-progress
> >hibernation if there is keyboard event. No attempt is made to suppress
> this
> >behavior. If desired, a sysadmin can disable the keyboard as a wakeup
> device
> >using standard mechanisms such as:
> >
> >echo disabled >
> /sys/bus/vmbus/drivers/hyperv_keyboard/XXX/power/wakeup
> >(where XXX is the device's GUID)
> >
> >Reviewed-by: Michael Kelley <[email protected]>
> >Signed-off-by: Dexuan Cui <[email protected]>
> >---
> >
> >This is a RESEND of
> https://lkml.org/lkml/2019/11/24/115
> >
> >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?
>
> This will need an ack from the input driver maintainers, unless they
> want to give a blanket ack to this type of patches.
>
> --
> Thanks,
> Sasha
Hi Dmitry,
May I have your Acked-by for this patch?
Thanks,
-- Dexuan
> From: [email protected]
> <[email protected]> On Behalf Of Dexuan Cui
> Sent: Wednesday, January 15, 2020 11:53 AM
> > ...
> > On Mon, Jan 06, 2020 at 02:40:44PM -0800, Dexuan Cui wrote:
> > >Add suspend() and resume() functions so the Hyper-V virtual keyboard
> > >can participate in VM hibernation.
> > >
> > >Note that the keyboard is a "wakeup" device that could abort an in-progress
> > >hibernation if there is keyboard event. No attempt is made to suppress
> > this
> > >behavior. If desired, a sysadmin can disable the keyboard as a wakeup
> > device
> > >using standard mechanisms such as:
> > >
> > >echo disabled >
> > /sys/bus/vmbus/drivers/hyperv_keyboard/XXX/power/wakeup
> > >(where XXX is the device's GUID)
> > >
> > >Reviewed-by: Michael Kelley <[email protected]>
> > >Signed-off-by: Dexuan Cui <[email protected]>
> > >---
> > >
> > >This is a RESEND of https://lkml.org/lkml/2019/11/24/115 .
> >
> > >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?
> >
> > This will need an ack from the input driver maintainers, unless they
> > want to give a blanket ack to this type of patches.
> >
> > Thanks,
> > Sasha
>
> Hi Dmitry,
> May I have your Acked-by for this patch?
>
> Thanks
> -- Dexuan
It looks Dmitry may be on leave and there is no ACK from any input driver
maintainers. :-(
Sasha, for this patch, I would suggest it may as well go directly through the
Hyper-V tree because
1. It's really small and it's a pure Hyper-V change.
2. This is for a new functionality and it can not break any existing code.
3. I'm pretty sure it can not cause any merge conflict or build failure.
It's still wonderful to get an Ack or some comment from the input driver
maintainer(s), so maybe let's wait more time (e.g. a week?) and then I
suggust we proceed.
Thanks,
-- Dexuan
On Sat, Jan 25, 2020 at 01:59:03AM +0000, Dexuan Cui wrote:
>> From: [email protected]
>> <[email protected]> On Behalf Of Dexuan Cui
>> Sent: Wednesday, January 15, 2020 11:53 AM
>> > ...
>> > On Mon, Jan 06, 2020 at 02:40:44PM -0800, Dexuan Cui wrote:
>> > >Add suspend() and resume() functions so the Hyper-V virtual keyboard
>> > >can participate in VM hibernation.
>> > >
>> > >Note that the keyboard is a "wakeup" device that could abort an in-progress
>> > >hibernation if there is keyboard event. No attempt is made to suppress
>> > this
>> > >behavior. If desired, a sysadmin can disable the keyboard as a wakeup
>> > device
>> > >using standard mechanisms such as:
>> > >
>> > >echo disabled >
>> > /sys/bus/vmbus/drivers/hyperv_keyboard/XXX/power/wakeup
>> > >(where XXX is the device's GUID)
>> > >
>> > >Reviewed-by: Michael Kelley <[email protected]>
>> > >Signed-off-by: Dexuan Cui <[email protected]>
>> > >---
>> > >
>> > >This is a RESEND of https://lkml.org/lkml/2019/11/24/115 .
>> >
>> > >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?
>> >
>> > This will need an ack from the input driver maintainers, unless they
>> > want to give a blanket ack to this type of patches.
>> >
>> > Thanks,
>> > Sasha
>>
>> Hi Dmitry,
>> May I have your Acked-by for this patch?
>>
>> Thanks
>> -- Dexuan
>
>It looks Dmitry may be on leave and there is no ACK from any input driver
>maintainers. :-(
>
>Sasha, for this patch, I would suggest it may as well go directly through the
>Hyper-V tree because
>1. It's really small and it's a pure Hyper-V change.
>2. This is for a new functionality and it can not break any existing code.
>3. I'm pretty sure it can not cause any merge conflict or build failure.
>
>It's still wonderful to get an Ack or some comment from the input driver
>maintainer(s), so maybe let's wait more time (e.g. a week?) and then I
>suggust we proceed.
I'll queue it up via the hyperv tree, if anyone has any objections
please let me know.
--
Thanks,
Sasha