From: Sowmiya Sree Elavalagan <quic_ssreeela@quicinc.com>
To: Sidhanta Sahu <quic_sidhanta@quicinc.com>
Cc: <linux-wireless@vger.kernel.org>, <ath12k@lists.infradead.org>
Subject: Re: [PATCH v3]wifi: ath12k: Add firmware coredump collection support
Date: Mon, 1 Jul 2024 18:36:30 +0530 [thread overview]
Message-ID: <8ebc29cb-2e26-bd3c-6659-050fc25cedd2@quicinc.com> (raw)
In-Reply-To: <1624b548-334e-4391-a8e9-ff2aa5d81f80@quicinc.com>
On 6/27/2024 9:16 PM, Sidhanta Sahu wrote:
>
>
> On 3/25/2024 11:34 AM, Sowmiya Sree Elavalagan wrote:
>> In case of firmware assert snapshot of firmware memory is essential for
>> debugging. Add firmware coredump collection support for PCI bus.
>> Collect RDDM and firmware paging dumps from MHI and pack them in TLV
>> format and also pack various memory shared during QMI phase in separate
>> TLVs. Add necessary header and share the dumps to user space using dev
>> coredump framework. Coredump collection is disabled by default and can
>> be enabled using menuconfig. Dump collected for a radio is 55 MB
>> approximately.
>>
>> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.2.1-00201-QCAHKSWPL_SILICONZ-1
>>
>> Signed-off-by: Sowmiya Sree Elavalagan <quic_ssreeela@quicinc.com>
>> ---
>> v2:
>> - Fixed errors shown by ath12k-check
>> v3:
>> - Fixed SPDX comment style for coredump.c file
>> Changed Kconfig description.
>> ---
>> drivers/net/wireless/ath/ath12k/Kconfig | 10 ++
>> drivers/net/wireless/ath/ath12k/Makefile | 1 +
>> drivers/net/wireless/ath/ath12k/core.c | 2 +
>> drivers/net/wireless/ath/ath12k/core.h | 5 +
>> drivers/net/wireless/ath/ath12k/coredump.c | 51 ++++++
>> drivers/net/wireless/ath/ath12k/coredump.h | 80 +++++++++
>> drivers/net/wireless/ath/ath12k/hif.h | 9 +-
>> drivers/net/wireless/ath/ath12k/hw.c | 4 +-
>> drivers/net/wireless/ath/ath12k/mhi.c | 5 +
>> drivers/net/wireless/ath/ath12k/mhi.h | 4 +-
>> drivers/net/wireless/ath/ath12k/pci.c | 185 +++++++++++++++++++++
>> 11 files changed, 351 insertions(+), 5 deletions(-)
>> create mode 100644 drivers/net/wireless/ath/ath12k/coredump.c
>> create mode 100644 drivers/net/wireless/ath/ath12k/coredump.h
>>
>
>
>> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
>> index 391b6fb2bd42..f0cc4959faf5 100644
>> --- a/drivers/net/wireless/ath/ath12k/core.c
>> +++ b/drivers/net/wireless/ath/ath12k/core.c
>> @@ -1121,6 +1121,7 @@ static void ath12k_core_reset(struct work_struct *work)
>> reinit_completion(&ab->recovery_start);
>> atomic_set(&ab->recovery_count, 0);
>> + ath12k_coredump_collect(ab);
>
> 1. Can we confirm if the operation guarantees that the coredump has been successfully uploaded upon its completion? It would be helpful to understand the expected behavior of the system in the event of a successful or unsuccessful upload.
>
You would see the print "Uploading coredump" on the console upon successful upload of the coredump. In case if the dump collection fails on the driver side itself you would not see the debug message.
> 2. Is it safe to proceed with memory cleanup operations immediately after this call? Understanding the dependencies and potential risks associated with memory cleanup post-upload would be beneficial for maintaining system stability and avoiding potential issues.
>
If you see the implementation completely, we take a copy of the memory to be dumped in the above call and queue the work of uploading to user space. All this happens before we proceed with clean up. We cannot wait for clean up until coredump gets uploaded as it may delay the recovery process which is not accepted.
>> ath12k_core_pre_reconfigure_recovery(ab);
>> reinit_completion(&ab->reconfigure_complete);
>> @@ -1220,6 +1221,7 @@ struct ath12k_base *ath12k_core_alloc(struct device *dev, size_t priv_size,
>> INIT_WORK(&ab->restart_work, ath12k_core_restart);
>> INIT_WORK(&ab->reset_work, ath12k_core_reset);
>> INIT_WORK(&ab->rfkill_work, ath12k_rfkill_work);
>> + INIT_WORK(&ab->dump_work, ath12k_coredump_upload);
>> timer_setup(&ab->rx_replenish_retry, ath12k_ce_rx_replenish_retry, 0);
>> init_completion(&ab->htc_suspend);
Hi Sidhanta,
Please find my response inline.
Thanks,
Sowmiya Sree
prev parent reply other threads:[~2024-07-01 13:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 18:34 [PATCH v3]wifi: ath12k: Add firmware coredump collection support Sowmiya Sree Elavalagan
2024-03-25 20:15 ` Jeff Johnson
2024-06-20 14:08 ` Kalle Valo
2024-06-26 15:09 ` Kalle Valo
2024-06-27 15:17 ` Sowmiya Sree Elavalagan
2024-07-03 12:18 ` Sowmiya Sree Elavalagan
2024-06-27 15:46 ` Sidhanta Sahu
2024-07-01 13:06 ` Sowmiya Sree Elavalagan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ebc29cb-2e26-bd3c-6659-050fc25cedd2@quicinc.com \
--to=quic_ssreeela@quicinc.com \
--cc=ath12k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_sidhanta@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox