From: Matthew Leach <matthew.leach@collabora.com>
To: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Cc: Jeff Johnson <jjohnson@kernel.org>,
linux-wireless@vger.kernel.org, ath11k@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH] ath11k: workaround firmware bug where peer_id=0
Date: Tue, 14 Apr 2026 13:54:47 +0100 [thread overview]
Message-ID: <87a4v54s88.fsf@collabora.com> (raw)
In-Reply-To: <7dbc3836-c42c-4cbb-a50a-011d82a0ee81@oss.qualcomm.com> (Baochen Qiang's message of "Tue, 14 Apr 2026 15:06:33 +0800")
Hi Baochen,
Baochen Qiang <baochen.qiang@oss.qualcomm.com> writes:
> On 3/30/2026 3:57 PM, Matthew Leach wrote:
>> Hello,
>>
>> Matthew Leach <matthew.leach@collabora.com> writes:
>>
[...]
> for chips like QCA2066 and WCN6855 etc 0 is a valid value, however
> this is not for chips like QCN9074 etc.
>
> so a possible fix would be to add hardware ops based on chips: for
> QCN9074 we keep the existing validation on 0 in the ops, while for
> QCA2066 the ops is a null func. Or even simper we can remove the
> validation for all chips.
In that case, does it make sense to remove the condition check
if (rxcb->peer_id)
in ath11k_dp_rx_h_find_peer()? It looks like this has been used as a
small optimisation, where if peer_id isn't valid it skips checking for
it in the peer hash table. However, if on newer chips peer_id=0 is
valid, we should remove this?
Regards,
--
Matt
next prev parent reply other threads:[~2026-04-14 12:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 10:53 [PATCH] ath11k: workaround firmware bug where peer_id=0 Matthew Leach
2026-03-30 7:57 ` Matthew Leach
2026-04-14 7:06 ` Baochen Qiang
2026-04-14 12:54 ` Matthew Leach [this message]
2026-04-15 3:16 ` Baochen Qiang
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=87a4v54s88.fsf@collabora.com \
--to=matthew.leach@collabora.com \
--cc=ath11k@lists.infradead.org \
--cc=baochen.qiang@oss.qualcomm.com \
--cc=jjohnson@kernel.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.