Kalle Valo <kvalo@xxxxxxxxxx> writes: > Robert Marko <robert.marko@xxxxxxxxxx> writes: > >> On Wed, Mar 29, 2023 at 11:45 AM Kalle Valo <kvalo@xxxxxxxxxx> wrote: >> >>> >> @@ -5369,6 +5491,10 @@ static int ath11k_mac_copy_he_cap(struct ath11k *ar, >>> >> >>> >> he_cap_elem->mac_cap_info[1] &= >>> >> IEEE80211_HE_MAC_CAP1_TF_MAC_PAD_DUR_MASK; >>> >> + he_cap_elem->phy_cap_info[0] &= >>> >> + ~IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G; >>> >> + he_cap_elem->phy_cap_info[0] &= >>> >> + ~IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_80PLUS80_MHZ_IN_5G; >>> > >>> > This is causing a regression for us in OpenWrt at least on IPQ8074 but >>> > probably on all ath11k-supported HW. Cause 80+80 and 160MHz support >>> > bits are being cleared here so 160MHz is not being advertised after >>> > this patch. >>> >>> Oh man, not good. Robert, should we revert this patchset entirely? Of >>> course it would be better if Muna can submit quickly a fix, but I'm not >>> going to wait for long. >> >> I would prefer to see it get fixed, cause just removing the flag >> removal gets 160MHz working, but I am not sure about other flags as >> well. > > Ok, let's try to get it fixed then. Muna, can you comment and send a fix > ASAP? No reply from Muna. I'll try the new bugbot to open a bug for this regression: bugbot on -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
