[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5f2a900a-3c8e-4b16-bd91-500af7d0315e@oss.qualcomm.com>
Date: Wed, 2 Jul 2025 11:50:51 +0800
From: Baochen Qiang <baochen.qiang@....qualcomm.com>
To: Muhammad Usama Anjum <usama.anjum@...labora.com>,
Manivannan Sadhasivam <mani@...nel.org>,
Jeff Johnson <jjohnson@...nel.org>,
Jeff Hugo <jeff.hugo@....qualcomm.com>,
Youssef Samir <quic_yabdulra@...cinc.com>,
Matthew Leung <quic_mattleun@...cinc.com>, Yan Zhen <yanzhen@...o.com>,
Alexander Wilhelm <alexander.wilhelm@...termo.com>,
Alex Elder <elder@...nel.org>, Kunwu Chan <chentao@...inos.cn>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Siddartha Mohanadoss <smohanad@...eaurora.org>,
Sujeev Dias <sdias@...eaurora.org>,
Julia Lawall <julia.lawall@...6.fr>, John Crispin <john@...ozen.org>,
Muna Sinada <quic_msinada@...cinc.com>,
Venkateswara Naralasetty <quic_vnaralas@...cinc.com>,
Maharaja Kennadyrajan <quic_mkenna@...cinc.com>, mhi@...ts.linux.dev,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-wireless@...r.kernel.org, ath11k@...ts.infradead.org
Cc: kernel@...labora.com
Subject: Re: [PATCH 2/3] bus: mhi: don't deinitialize and re-initialize again
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@...labora.com>
> ---
> 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.
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.
> 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.
Powered by blists - more mailing lists