On Thu, Jan 04, 2024 at 11:39:12AM +0530, Manivannan Sadhasivam wrote: + Can, Qiang [...] > > > To me it all sounds like the probe deferral is not handled properly in mac80211 > > > stack. As you mentioned in the commit message that the dpm_prepare() blocks > > > probing of devices. It gets unblocked and trigerred in dpm_complete(): > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/power/main.c#n1131 > > > > > > So if mac80211/ath11k cannot probe the devices at the dpm_complete() stage, then > > > it is definitely an issue that needs to be fixed properly. > > To clarify, ath11k CAN probe the devices at dpm_complete() stage. The > > problem is kernel does not wait for all probes to finish, and in that way we > > will face the issue that user space applications are likely to fail because > > they get thawed BEFORE WLAN is ready. > > > > Hmm. Please give me some time to reproduce this issue locally. I will get back > to this thread with my analysis. > We reproduced the issue with the help of PCIe team (thanks Can). What we found out was, during the resume from hibernation the faliure happens in ath11k_core_resume(). Precisely here: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers/net/wireless/ath/ath11k/core.c?h=ath11k-hibernation-support#n850 This code waits for the QMI messages to arrive and eventually timesout. But the impression I got from the start was that the mhi_power_up() always fails during resume. In our investigation, we confirmed that the failure is not happening at the MHI level. I'm not pointing fingers here, but trying to understand why can't you fix ath11k_core_resume() to not timeout? IMO this timeout should be handled as a deferral case. - Mani -- மணிவண்ணன் சதாசிவம்
