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;
MIME-Version: 1.0
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> <87fs9ndh6s.fsf@kernel.org>
In-Reply-To: <87fs9ndh6s.fsf@kernel.org>
From:   Robert Marko <robert.marko@sartura.hr>
Date:   Wed, 29 Mar 2023 12:42:34 +0200
Message-ID: <CA+HBbNEaNTkUv_UPgQievxaLya0XC6=AVj0=GWiH+qB9=vRZHg@mail.gmail.com>
Subject: Re: [PATCH v2 2/4] wifi: ath11k: push MU-MIMO params from hostapd to hardware
To:     Kalle Valo <kvalo@kernel.org>
Cc:     Muna Sinada <quic_msinada@quicinc.com>, ath11k@lists.infradead.org,
        linux-wireless@vger.kernel.org,
        Anilkumar Kolli <quic_akolli@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Mar 29, 2023 at 11:45=E2=80=AFAM Kalle Valo <kvalo@kernel.org> wrot=
e:
>
> Robert Marko <robert.marko@sartura.hr> writes:
>
> > On Tue, Oct 18, 2022 at 11:28=E2=80=AFPM Muna Sinada <quic_msinada@quic=
inc.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=3D683=
322&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_160MH=
Z_IN_5G;
> >> +               he_cap_elem->phy_cap_info[0] &=3D
> >> +                       ~IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_80PLU=
S80_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.

Regards,
Robert
>
> 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 m=
cs
>
> > I fail to understand why are 80+80 and 160 MHz feature flags being clea=
red?
>
> Me neither. I missed that in my review.
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpa=
tches


--=20
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@sartura.hr
Web: www.sartura.hr