Hi, I've been digging in the MHI code to find the reason behind broken resume from hibernation for MHI. The same resume function is used for both resume from suspend and resume from hibernation. The resume from suspend works fine because at resume time the state of MHI is MHI_STATE_M3. On the other hand, the state is MHI_STATE_RESET when we resume from hibernation. It seems resume from MHI_STATE_RESET state isn't correctly supported. The channel state is MHI_CH_STATE_ENABLED at this point. We get error while switching channel state from MHI_CH_STATE_ENABLE to MHI_CH_STATE_RUNNING. Hence, channel state change fails and later mhi resume fails as well. I've put some debug prints to understand the issue. These may be helpful: [ 669.032683] mhi_update_channel_state: switch to MHI_CH_STATE_TYPE_START[2] channel state not possible cuzof channel current state[1]. mhi state: [0] Return -EINVAL [ 669.032685] mhi_prepare_channel: mhi_update_channel_state to MHI_CH_STATE_TYPE_START[2] returned -22 [ 669.032693] qcom_mhi_qrtr mhi0_IPCR: failed to prepare for autoqueue transfer -22 This same error has been reported on some fix patches [1] [2]. Are there any patches which I should test? Is officially hibernation use case supported at all? In my view, this path may not have gotten tested and can be fixed easily as we need to perform, more or less the same steps which were performed at init time. But I've not found much documentation around MHI protocol and its state machine, how is mhi state related to mhi channels support. PS: Just some information, my device has QCNFA765 endpoint and ath11k_pci is being used. It doesn't seem like the problem is in the driver. The problem is on the host side which isn't able to communicate correctly with the endpoint. The resume from hibernation would be broken on all wifi chips using mhi. [1] https://lore.kernel.org/all/Z5EKrbXMTK9WBsbq@xxxxxxxxxxxxxxxxxxxx [2] https://lore.kernel.org/all/Z5ENq9EMPlNvxNOF@xxxxxxxxxxxxxxxxxxxx -- BR, Muhammad Usama Anjum
