For whatever reason, some devices like QCA6390, WCN6855 using ath11k are not in M3 state during PM resume, but still functional. The mhi_pm_resume should then not fail in those cases, and let the higher level device specific stack continue resuming process. Add an API mhi_pm_resume_force(), to force resuming irrespective of the current MHI state. This fixes a regression with non functional ath11k WiFi after suspend/resume cycle on some machines. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=214179
Showing the changes to include/linux (1 of 3 files). Show all
Unified · Split
| @@ -663,6 +663,19 @@ int mhi_pm_suspend(struct mhi_controller *mhi_cntrl); · 662 unmodified lines | ||
| 663 | 663 | */ |
| 664 | 664 | int mhi_pm_resume(struct mhi_controller *mhi_cntrl); |
| 665 | 665 | |
| 666 | +/** | |
| 667 | + * mhi_pm_resume_force - Force resume MHI from suspended state | |
| 668 | + * @mhi_cntrl: MHI controller | |
| 669 | + * | |
| 670 | + * Resume the device irrespective of its MHI state. As per the MHI spec, devices | |
| 671 | + * has to be in M3 state during resume. But some devices seem to be in a | |
| 672 | + * different MHI state other than M3 but they continue working fine if allowed. | |
| 673 | + * This API is intented to be used for such devices. | |
| 674 | + * | |
| 675 | + * Return: 0 if the resume succeeds, a negative error code otherwise | |
| 676 | + */ | |
| 677 | +int mhi_pm_resume_force(struct mhi_controller *mhi_cntrl); | |
| 678 | + | |
| 666 | 679 | /** |
| 667 | 680 | * mhi_download_rddm_image - Download ramdump image from device for |
| 668 | 681 | * debugging purpose. |