Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Kalle Valo <kvalo@kernel.org>
To:     Robert Marko <robert.marko@sartura.hr>
Cc:     Muna Sinada <quic_msinada@quicinc.com>, ath11k@lists.infradead.org,
        linux-wireless@vger.kernel.org,
        Anilkumar Kolli <quic_akolli@quicinc.com>
Subject: Re: [PATCH v2 2/4] wifi: ath11k: push MU-MIMO params from hostapd to hardware
References: <1666128501-12364-1-git-send-email-quic_msinada@quicinc.com>
        <1666128501-12364-3-git-send-email-quic_msinada@quicinc.com>
        <CA+HBbNHw-0+Ty_-masxGKwT6ju_EBxT3n5B0Ygcn3XzQi_CzWg@mail.gmail.com>
Date:   Wed, 29 Mar 2023 12:45:31 +0300
In-Reply-To: <CA+HBbNHw-0+Ty_-masxGKwT6ju_EBxT3n5B0Ygcn3XzQi_CzWg@mail.gmail.com>
        (Robert Marko's message of "Tue, 28 Mar 2023 13:11:22 +0200")
Message-ID: <87fs9ndh6s.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Robert Marko <robert.marko@sartura.hr> writes:

> On Tue, Oct 18, 2022 at 11:28=E2=80=AFPM Muna Sinada <quic_msinada@quicin=
c.com> wrote:
>
>>
>> In the previous behaviour only HE IE in management frames are changed
>> regarding MU-MIMO configurations and not in hardware. Adding push of
>> MU-MIMO configurations to the hardware as well.
>>
>> This patch is dependant on mac80211 patchset:
>> https://patchwork.kernel.org/project/linux-wireless/list/?series=3D68332=
2&state=3D%2A&archive=3Dboth
>>
>> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00356-QCAHKSWPL_SILICONZ-1
>>
>> Co-developed-by: Anilkumar Kolli <quic_akolli@quicinc.com>
>> Signed-off-by: Anilkumar Kolli <quic_akolli@quicinc.com>
>> Signed-off-by: Muna Sinada <quic_msinada@quicinc.com>

[...]

>> @@ -5369,6 +5491,10 @@ static int ath11k_mac_copy_he_cap(struct ath11k *=
ar,
>>
>>                 he_cap_elem->mac_cap_info[1] &=3D
>>                         IEEE80211_HE_MAC_CAP1_TF_MAC_PAD_DUR_MASK;
>> +               he_cap_elem->phy_cap_info[0] &=3D
>> +                       ~IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_=
IN_5G;
>> +               he_cap_elem->phy_cap_info[0] &=3D
>> +                       ~IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_80PLUS8=
0_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.

The patchset is in wireless-next at the moment and the commits from the
patchset are:

a96f10422e74 wifi: ath11k: modify accessor macros to match index size
38dfe775d0ab wifi: ath11k: push MU-MIMO params from hostapd to hardware
8077c1bbbc28 wifi: ath11k: move HE MCS mapper to a separate function
ebf82988f844 wifi: ath11k: generate rx and tx mcs maps for supported HE mcs

> I fail to understand why are 80+80 and 160 MHz feature flags being cleare=
d?

Me neither. I missed that in my review.

--=20
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatc=
hes