All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.