Muna Sinada <quic_msinada@xxxxxxxxxxx> writes: > 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 I have created fix, tested it and pushed internally for review. @Kalle, how do I go about continuing the conversation on Bugzilla?
