forked from ~ljy/RK356X_SDK_RELEASE

hc
2024-01-31 f70575805708cabdedea7498aaa3f710fde4d920
kernel/drivers/hv/hv_kvp.c
....@@ -27,6 +27,7 @@
2727 #include <linux/connector.h>
2828 #include <linux/workqueue.h>
2929 #include <linux/hyperv.h>
30
+#include <asm/hyperv-tlfs.h>
3031
3132 #include "hyperv_vmbus.h"
3233 #include "hv_utils_transport.h"
....@@ -353,7 +354,7 @@
353354
354355 out->body.kvp_ip_val.dhcp_enabled = in->kvp_ip_val.dhcp_enabled;
355356
356
- /* fallthrough */
357
+ fallthrough;
357358
358359 case KVP_OP_GET_IP_INFO:
359360 utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.adapter_id,
....@@ -437,7 +438,7 @@
437438 val32 = in_msg->body.kvp_set.data.value_u32;
438439 message->body.kvp_set.data.value_size =
439440 sprintf(message->body.kvp_set.data.value,
440
- "%d", val32) + 1;
441
+ "%u", val32) + 1;
441442 break;
442443
443444 case REG_U64:
....@@ -661,7 +662,7 @@
661662 if (kvp_transaction.state > HVUTIL_READY)
662663 return;
663664
664
- vmbus_recvpacket(channel, recv_buffer, PAGE_SIZE * 4, &recvlen,
665
+ vmbus_recvpacket(channel, recv_buffer, HV_HYP_PAGE_SIZE * 4, &recvlen,
665666 &requestid);
666667
667668 if (recvlen > 0) {
....@@ -757,11 +758,50 @@
757758 return 0;
758759 }
759760
760
-void hv_kvp_deinit(void)
761
+static void hv_kvp_cancel_work(void)
761762 {
762
- kvp_transaction.state = HVUTIL_DEVICE_DYING;
763763 cancel_delayed_work_sync(&kvp_host_handshake_work);
764764 cancel_delayed_work_sync(&kvp_timeout_work);
765765 cancel_work_sync(&kvp_sendkey_work);
766
+}
767
+
768
+int hv_kvp_pre_suspend(void)
769
+{
770
+ struct vmbus_channel *channel = kvp_transaction.recv_channel;
771
+
772
+ tasklet_disable(&channel->callback_event);
773
+
774
+ /*
775
+ * If there is a pending transtion, it's unnecessary to tell the host
776
+ * that the transaction will fail, because that is implied when
777
+ * util_suspend() calls vmbus_close() later.
778
+ */
779
+ hv_kvp_cancel_work();
780
+
781
+ /*
782
+ * Forece the state to READY to handle the ICMSGTYPE_NEGOTIATE message
783
+ * later. The user space daemon may go out of order and its write()
784
+ * may fail with EINVAL: this doesn't matter since the daemon will
785
+ * reset the device by closing and re-opening it.
786
+ */
787
+ kvp_transaction.state = HVUTIL_READY;
788
+ return 0;
789
+}
790
+
791
+int hv_kvp_pre_resume(void)
792
+{
793
+ struct vmbus_channel *channel = kvp_transaction.recv_channel;
794
+
795
+ tasklet_enable(&channel->callback_event);
796
+
797
+ return 0;
798
+}
799
+
800
+void hv_kvp_deinit(void)
801
+{
802
+ kvp_transaction.state = HVUTIL_DEVICE_DYING;
803
+
804
+ hv_kvp_cancel_work();
805
+
766806 hvutil_transport_destroy(hvt);
767807 }