[PATCH v2 2/4] wifi: ath11k: push MU-MIMO params from hostapd to hardware

[Muna Sinada (QUIC)]

Muna Sinada <quic_msinada at quicinc.com> writes:
> Kalle Valo <kvalo at kernel.org> writes:
>> Robert Marko <robert.marko at sartura.hr> writes:
>>
>>> On Wed, Mar 29, 2023 at 11:45 AM Kalle Valo <kvalo at kernel.org> 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?