Re: [PATCH 2/3] bus: mhi: don't deinitialize and re-initialize again

[Muhammad Usama Anjum]

Thank you for reviewing.

On 7/2/25 8:50 AM, Baochen Qiang wrote:
> 
> 
> On 6/30/2025 3:43 PM, Muhammad Usama Anjum wrote:
>> Don't deinitialize and reinitialize the HAL helpers. The dma memory is
>> deallocated and there is high possibility that we'll not be able to get
>> the same memory allocated from dma when there is high memory pressure.
>>
>> Tested-on: WCN6855 WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.6
>>
>> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@xxxxxxxxxxxxx>
>> ---
>>  drivers/net/wireless/ath/ath11k/core.c | 5 -----
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
>> index 4488e4cdc5e9e..bc4930fe6a367 100644
>> --- a/drivers/net/wireless/ath/ath11k/core.c
>> +++ b/drivers/net/wireless/ath/ath11k/core.c
>> @@ -2213,14 +2213,9 @@ static int ath11k_core_reconfigure_on_crash(struct ath11k_base *ab)
>>  	mutex_unlock(&ab->core_lock);
>>  
>>  	ath11k_dp_free(ab);
>> -	ath11k_hal_srng_deinit(ab);
>>  
>>  	ab->free_vdev_map = (1LL << (ab->num_radios * TARGET_NUM_VDEVS(ab))) - 1;
>>  
>> -	ret = ath11k_hal_srng_init(ab);
>> -	if (ret)
>> -		return ret;
>> -
> 
> while I agree there is no need of a dealloc/realloc, we can not simply remove calling the
> _deinit()/_init() pair. At least the memset() cleanup to hal parameters (e.g.
Why do is it being done in the resume handler? Shouldn't those parameters be cleaned up
in resume handler? So when device wakes up, its state is already correct.

I'm not sure why it worked every time when I tested it on my device.

> avail_blk_resource, current_blk_index and num_shadow_reg_configured etc.) inside the
> _init() needs to be kept as the later operation needs a clean state of them.
So should we just memset these 3?


> 
>>  	clear_bit(ATH11K_FLAG_CRASH_FLUSH, &ab->dev_flags);
>>  
>>  	ret = ath11k_core_qmi_firmware_ready(ab);
> 
> the _deinit() is still getting called in case ath11k_core_qmi_firmware_ready() fails,
> making it a little odd since there is no _init() anymore with this change, though this is
> the way of current logic (I mean the hal is currently deinit in the error path).
> 
> Thinking it more, if we hit the error path, seems the only way is to remove ath11k module.
> In that case the _deinit() would be called again in ath11k_pci_remove(), leading to issues
> (at least I see a double free of hal->srng_config). But this is another topic which can be
> fixed in a separate patch.

I don't think this is the problem as HAL is already initialized when before the system has
suspended. So by removing deinit() and init() pairs, the HAL still remains initialized. Or
maybe I've missed something?