On Thu, Jul 17, 2025 at 03:46:00PM +0200, Johannes Berg wrote: > Hi, > > On Thu, 2025-07-17 at 15:21 +0200, Remi Pommarel wrote: > > I have ordered a mt7921 card so I could reproduce this and finally took > > time to debug that. > > Oh wow, talk about dedication. Thank you! > > > The issue comes to the fact that mt7921 uses 802.11 > > encapsulation offloading and as such we are calling > > ieee80211_tx_h_select_key() on a 802.3 frame. > > Oh... Guess we could've thought about that, sorry. Though I would've > thought ath12k will also do that. Maybe not in the config you were > seeing the issue in? I've mainly tested on ath*k HW. Either without 802.11 encapsulation HW offloading or with it but only on ath12k and it seems that this driver does not need the key in this mode. After a quick look into ath11k and 10k that also seems to be the case for those chips. For the record, if I am not mistaken, ath12k driver does not seem to support 802.11 encaps HW offloading mainline yet, I do seem to have some vendor patches to support it though. > > > This function casts the skb data as a 802.11 header regardless the skb > > is 802.11 or not in order to decide if the info->control.hw_key needs to > > be set. So the hw_key is likely to remain NULL in ieee80211_tx_dequeue() > > and because mt7921 driver needs this key to be valid data frames are > > dropped. > > > > Will send a patch so that ieee80211_tx_h_select_key() does not try to > > get info from a ieee80211_hdr mapped on 802.3 packet data (i.e. when > > IEEE80211_TX_CTL_HW_80211_ENCAP is set). > > > > Sounds good! > > johannes -- Remi
