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? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
