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 | int mhi_pm_resume(struct mhi_controller *mhi_cntrl); | 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 | * mhi_download_rddm_image - Download ramdump image from device for | 680 | * mhi_download_rddm_image - Download ramdump image from device for |
| 668 | * debugging purpose. | 681 | * debugging purpose. |