Re: [PATCH v3] ath11k: fix peer resolution on rx path when peer_id=0

[Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>]

On 4/17/2026 4:37 PM, Matthew Leach wrote:
> It has been observed that on certain chipsets a peer can be assigned
> peer_id=0. For reception of non-aggregated MPDUs this is fine as
> ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
> based upon the source MAC address. On an aggregated link, the mpdu_start
> header is only populated by hardware on the first sub-MSDU. This causes
> the peer resolution to be skipped for the subsequent MSDUs and the
> encryption type of these frames to be set to an incorrect value,
> resulting in these MSDUs being dropped by ieee80211.
> 
> ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
> ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
> 
> Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
> ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
> of 0 to be resolved.
> 

Please add a Fixes: tag, since this addresses a real RX-path bug.
At least the dp_rx.c change seems to trace back to
2167fa606c0f ("ath11k: Add support for RX decapsulation offload").

Please also use the usual wireless subject prefix, e.g.
wifi: ath11k: fix peer resolution on rx path when peer_id=0

It would also be useful to add a Tested-on: tag if this was validated on
affected hardware, as suggested in the ath11k submission guidelines.