From: Nazar Mokrynskyi <nazar@mokrynskyi.com>
To: Jeff Johnson <jeff.johnson@oss.qualcomm.com>, ath12k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] wifi: ath12k: skip unknown direct buffer ring module IDs
Date: Mon, 11 May 2026 23:10:13 +0300 [thread overview]
Message-ID: <07a1e340-cfdf-4027-861e-8f2a940bd21c@mokrynskyi.com> (raw)
In-Reply-To: <89f30996-3210-403b-8c9a-52cf6d5fcb51@oss.qualcomm.com>
11.05.26 22:02, Jeff Johnson:
> On 5/5/2026 10:24 AM, Nazar Mokrynskyi wrote:
>> The firmware may advertise direct buffer ring capabilities for module
>> IDs beyond what the driver currently knows about (WMI_DIRECT_BUF_MAX).
>> This happens with newer firmware versions that support additional ring
>> types not yet implemented in the driver.
> What "newer firmware version" are you using that has this issue?
>
> Can you share the "Skipping unknown direct buf ring module id" logs from your
> modified driver?
ID is the same as in the original warning:
[ 10.611560] ath12k_pci 0000:01:00.0: Invalid module id 2
[ 10.616467] ath12k_pci 0000:01:00.0: failed to parse tlv -22
The firmware according to system logs (all this info is provided in [PATCH 0/2] email):
[ 7.688137] ath12k_pci 0000:01:00.0: fw_version 0x160484db fw_build_timestamp 2025-12-09 20:09 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
This is running on OpenWRT 25.12, which uses 6.12.74 kernel with modules backported from 6.18.7 kernel:
[ 0.000000] Linux version 6.12.74 (builder@buildhost) (x86_64-openwrt-linux-musl-gcc (OpenWrt GCC 14.3.0 r32802-f505120278) 14.3.0, GNU ld (GNU Binutils) 2.44) #0 SMP Wed Mar 25 20:09:53 2026
[ 6.997293] Loading modules backported from Linux version v6.18.7-0-g5dfbc5357
[ 6.999210] Backport generated by backports.git c8a37ce
>> The current code treats an unknown module_id as a fatal error, returning
>> -EINVAL and tearing down the entire driver initialization. This is
>> incorrect: the driver only needs to set up rings for types it uses
>> (SPECTRAL=0, CFR=1) and can safely ignore capability advertisements for
>> unknown types.
>>
>> Change the unknown module_id handling to skip the entry with a debug
>> message rather than failing, allowing initialization to proceed.
>>
>> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>>
>> Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
>> ---
>> drivers/net/wireless/ath/ath12k/wmi.c | 12 ++++--------
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
>> index 484fdd3b1..0e776a8d8 100644
>> --- a/drivers/net/wireless/ath/ath12k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
>> @@ -4814,10 +4814,10 @@ static int ath12k_wmi_dma_ring_caps(struct ath12k_base *ab,
>> dir_buff_caps = ab->db_caps;
>> for (i = 0; i < dma_caps_parse->n_dma_ring_caps; i++) {
>> if (le32_to_cpu(dma_caps[i].module_id) >= WMI_DIRECT_BUF_MAX) {
>> - ath12k_warn(ab, "Invalid module id %d\n",
>> - le32_to_cpu(dma_caps[i].module_id));
>> - ret = -EINVAL;
>> - goto free_dir_buff;
>> + ath12k_dbg(ab, ATH12K_DBG_WMI,
>> + "Skipping unknown direct buf ring module id %d\n",
>> + le32_to_cpu(dma_caps[i].module_id));
>> + continue;
> by continuing you don't populate the dir_buff_caps[i] information below,
> leaving that record with zeroed data from the initial allocation. Does other
> code correctly handle that?
>
> would it be better to have a separate count of the number of dir_buff_caps
> records that are actually filled, and then update
> dma_caps_parse->n_dma_ring_caps to match once the parsing has completed?
I'm very far from kernel development, let alone ath12k driver specifically.
The patch is provided to better showcase the problems I had.
If there is a better way to address it, I'd really appreciate if someone more knowledgeable could take over, I just hope this is helpful.
With these changes QCN9274 runs an access point with over 3 weeks uptime as of right now.
That is not necessary the proof of anything, but it does seem to work in practice so far.
>> }
>>
>> dir_buff_caps[i].id = le32_to_cpu(dma_caps[i].module_id);
>> @@ -4829,10 +4829,6 @@ static int ath12k_wmi_dma_ring_caps(struct ath12k_base *ab,
>> }
>>
>> return 0;
>> -
>> -free_dir_buff:
>> - ath12k_wmi_free_dbring_caps(ab);
>> - return ret;
>> }
>>
>> static void
prev parent reply other threads:[~2026-05-11 20:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 17:24 [PATCH 0/2] wifi: ath12k: Fix operation under virtio Nazar Mokrynskyi
2026-05-05 17:24 ` [PATCH 1/2] wifi: ath12k: skip PCIe global reset on initial power-up Nazar Mokrynskyi
2026-05-05 17:24 ` [PATCH 2/2] wifi: ath12k: skip unknown direct buffer ring module IDs Nazar Mokrynskyi
2026-05-11 19:02 ` Jeff Johnson
2026-05-11 20:10 ` Nazar Mokrynskyi [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=07a1e340-cfdf-4027-861e-8f2a940bd21c@mokrynskyi.com \
--to=nazar@mokrynskyi.com \
--cc=ath12k@lists.infradead.org \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
/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