On 2/20/2024 7:00 PM, Baochen Qiang wrote: > ath11k fails to resume: > > ath11k_pci 0000:06:00.0: timeout while waiting for restart complete > > This happens because when calling mhi_sync_power_up() the MHI subsystem > eventually calls device_add() from mhi_create_devices() but the device > creation is deferred: > > mhi mhi0_IPCR: Driver qcom_mhi_qrtr force probe deferral > > The reason for deferring device creation is explained in dpm_prepare(): > > /* > * It is unsafe if probing of devices will happen during suspend or > * hibernation and system behavior will be unpredictable in this case. > * So, let's prohibit device's probing here and defer their probes > * instead. The normal behavior will be restored in dpm_complete(). > */ > > Because the device probe is deferred, the qcom_mhi_qrtr_probe() is not > called and thus MHI channels are not prepared: > > So what this means that QRTR is not delivering messages and the QMI connection > is not working between ath11k and the firmware, resulting a failure in firmware > initialization. > > To fix this add new function mhi_power_down_no_destroy() which doesn't destroy > the devices for channels during power down. This way we avoid probe defer issue > and finally can get ath11k hibernation working with the following patches. > > Actually there is an RFC version of this change and it gets positive results > from multiple users. Firstly Mani doesn't like this idea and insists that an > MHI device should be destroyed when going to suspend/hibernation, see > > https://lore.kernel.org/mhi/20231127162022.518834-1-kvalo@xxxxxxxxxx/ > > Then Mani changed his mind after a further discussion with kernel PM guys, > see > > https://lore.kernel.org/all/21cd2098-97e1-4947-a5bb-a97582902ead@xxxxxxxxxxx/ > > So we come up with the regular version and it is almost identical with that RFC > version. > > Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 > > Signed-off-by: Kalle Valo <quic_kvalo@xxxxxxxxxxx> > Signed-off-by: Baochen Qiang <quic_bqiang@xxxxxxxxxxx> Reviewed-by: Jeff Johnson <quic_jjohnson@xxxxxxxxxxx>
