"Muna Sinada (QUIC)" <quic_msinada@xxxxxxxxxxx> writes: > 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? Better to continue the discussion on the list. I only created the bug on Bugzilla so that I don't forget this as I didn't hear anything from you. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
