Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
On 5/6/2024 6:04 PM, Kalle Valo wrote: (...) This is of course just a theory. I don't know how familiar you are with 802.11 protocols but that is something to investigate. Unfortunately I have very little time for ath10k nowadays. Not very familiar with 802.11 protocols, I'm just a user. Until it can be fixed can PMF be disabled for the QCA6174 card? - Eric
Re: [PATCH v3 1/3] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Marc Gonzalez writes: > On 30/04/2024 06:06, Kalle Valo wrote: > >> Bjorn Andersson wrote: >> >>> On Mon, Apr 29, 2024 at 04:04:51PM +0200, Marc Gonzalez wrote: >>> The ath10k driver waits for an "MSA_READY" indicator to complete initialization. If the indicator is not received, then the device remains unusable. cf. ath10k_qmi_driver_event_work() Several msm8998-based devices are affected by this issue. Oddly, it seems safe to NOT wait for the indicator, and proceed immediately when QMI_EVENT_SERVER_ARRIVE. Jeff Johnson wrote: The feedback I received was "it might be ok to change all ath10k qmi to skip waiting for msa_ready", and it was pointed out that ath11k (and ath12k) do not wait for it. However with so many deployed devices, "might be ok" isn't a strong argument for changing the default behavior. Kalle Valo first suggested setting a bit in firmware-5.bin to trigger work-around in the driver. However, firmware-5.bin is parsed too late. So we are stuck with a DT property. Signed-off-by: Pierre-Hugues Husson Signed-off-by: Marc Gonzalez >>> >>> This says "Pierre-Hugues certifies the origin of the patch" then "Marc >>> certifies the origin of the patch". This would have to imply that >>> Pierre-Hugues authored the patch, but you're listed as the author... >>> >>> Perhaps a suitable answer to this question would be to add >>> "Co-developed-by: Pierre-Hugues ..." above his s-o-b, which implies that >>> the two of you jointly came up with this and both certify the origin. >> >> BTW I can add that in the pending branch, no need to resend because of >> this. Just need guidance from Marc. > > I typed this patch all by myself with my grubby little paws. > You can drop PH's S-o-b. > >>> Other than that, I think this looks good, so please upon addressing this >>> problem feel free to add my: >>> >>> Reviewed-by: Bjorn Andersson >> >> Thanks, I'll then add this as well. > > Cool. Almost there :) All I need is an ack from DT maintainers for this patch. DT maintainers: I think this is the best option and I can't think of any other solution so I would prefer to take this approach to our ath.git tree if it's ok for you. IIRC someone suggested testing for firmware version string but I suspect that has the same problem as the firmware-N.bin approach: ath10k gets the firmware version too late. And besides it's difficult to maintain such a list in ath10k, it would always need kernel updates when there's a new firmware etc. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v3 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
On 29/04/2024 16:07, Marc Gonzalez wrote:
> The ath10k driver waits for an "MSA_READY" indicator
> to complete initialization. If the indicator is not
> received, then the device remains unusable.
>
> cf. ath10k_qmi_driver_event_work()
>
> Several msm8998-based devices are affected by this issue.
> Oddly, it seems safe to NOT wait for the indicator, and
> proceed immediately when QMI_EVENT_SERVER_ARRIVE.
>
> Jeff Johnson wrote:
>
> The feedback I received was "it might be ok to change all ath10k qmi
> to skip waiting for msa_ready", and it was pointed out that ath11k
> (and ath12k) do not wait for it.
>
> However with so many deployed devices, "might be ok" isn't a strong
> argument for changing the default behavior.
>
> cf. also
> https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN
>
> Signed-off-by: Marc Gonzalez
> ---
> arch/arm64/boot/dts/qcom/msm8998.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> index 67b8374ddf02f..4e6245095adfc 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> @@ -3234,6 +3234,7 @@ wifi: wifi@1880 {
> iommus = <&anoc2_smmu 0x1900>,
><&anoc2_smmu 0x1901>;
> qcom,snoc-host-cap-8bit-quirk;
> + qcom,no-msa-ready-indicator;
> };
> };
> };
Bjorn,
This patch is supposed to go through your tree, right?
Regards
Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
Eric Park writes: > I had the opportunity to test the connection with another router (Asus > RT-AX56U) today and it negotiated with WPA2-PSK, PMF default on, on 5 > GHz. I ran a speedtest and got 20 Mbps both up/down. > > I then ran the `nmcli connection modify wifi-sec.pmf 1` and > after reconnecting it connected with PMF disabled. (I think the reason > it worked this time is because of WPA2-PSK -- there's probably some > way of making it work with WPA3 APs and `nmcli` but I don't know the > correct commands to give in order to make that happen.) The speedtest > increased to 100 Mbps both up/down, and that's the WAN limit -- I'm > pretty sure if I ran a iperf3 inside the LAN it would've been much > faster. > > I think the PMF implementation in ath10k, at least for the QCA6174 > chip, has some issues as it has consistently worsened performance on > two out of two sample APs I've tested it on. Yeah, clearly something is wrong somewhere but difficult to say where exactly. I got a private comment that one possible cause might be that the first ADDBA frame is not decrypted correctly and the aggregation is not working. Broken aggregation would explain the decrease in throughput. This is of course just a theory. I don't know how familiar you are with 802.11 protocols but that is something to investigate. Unfortunately I have very little time for ath10k nowadays. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
