[kvalo-ath:master-pending] BUILD SUCCESS be56e136228b8c286ca81c3391f4d091a7af6722
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git master-pending branch HEAD: be56e136228b8c286ca81c3391f4d091a7af6722 Merge branch 'pending' into master-pending elapsed time: 1531m configs tested: 103 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allnoconfig gcc arc defconfig gcc arc randconfig-001-20240426 gcc arc randconfig-002-20240426 gcc arm allnoconfig clang arm defconfig clang arm randconfig-001-20240426 clang arm randconfig-002-20240426 gcc arm randconfig-003-20240426 gcc arm randconfig-004-20240426 gcc arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240426 gcc arm64 randconfig-002-20240426 gcc csky allnoconfig gcc cskydefconfig gcc csky randconfig-001-20240426 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang i386 allmodconfig gcc i386 allnoconfig gcc i386 buildonly-randconfig-001-20240425 gcc i386 buildonly-randconfig-002-20240425 clang i386 buildonly-randconfig-003-20240425 gcc i386 buildonly-randconfig-004-20240425 clang i386 buildonly-randconfig-005-20240425 clang i386 buildonly-randconfig-006-20240425 gcc i386defconfig clang i386 randconfig-001-20240425 clang i386 randconfig-002-20240425 clang i386 randconfig-003-20240425 clang i386 randconfig-004-20240425 gcc i386 randconfig-005-20240425 clang i386 randconfig-006-20240425 clang i386 randconfig-011-20240425 clang i386 randconfig-012-20240425 clang i386 randconfig-013-20240425 gcc i386 randconfig-014-20240425 gcc i386 randconfig-015-20240425 gcc i386 randconfig-016-20240425 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allnoconfig gcc mips allyesconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allnoconfig gcc openriscdefconfig gcc pariscallnoconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allnoconfig gcc riscv allnoconfig gcc riscv defconfig clang s390 allmodconfig clang s390 allnoconfig clang s390 allyesconfig gcc s390defconfig clang sh allmodconfig gcc shallnoconfig gcc sh allyesconfig gcc sh defconfig gcc sparcallmodconfig gcc sparc allnoconfig gcc sparc defconfig gcc sparc64 allmodconfig gcc sparc64 allyesconfig gcc sparc64 defconfig gcc um allmodconfig clang um
[kvalo-ath:pending-deferred] BUILD SUCCESS 6b77c16df2afe4565e54c2cc4f80c66f25840d04
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending-deferred branch HEAD: 6b77c16df2afe4565e54c2cc4f80c66f25840d04 wifi: ath10k: mac: enable WIPHY_FLAG_CHANNEL_CHANGE_ON_BEACON on ath10k elapsed time: 1461m configs tested: 128 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allnoconfig gcc arc axs101_defconfig gcc arc axs103_defconfig gcc arc defconfig gcc arc haps_hs_defconfig gcc arm allnoconfig clang arm collie_defconfig gcc arm defconfig clang arm randconfig-001-20240425 clang arm randconfig-002-20240425 clang arm randconfig-003-20240425 clang arm randconfig-004-20240425 clang arm s3c6400_defconfig gcc arm sp7021_defconfig gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc csky allnoconfig gcc cskydefconfig gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang hexagon randconfig-001-20240425 clang hexagon randconfig-002-20240425 clang i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20240425 gcc i386 buildonly-randconfig-002-20240425 clang i386 buildonly-randconfig-003-20240425 gcc i386 buildonly-randconfig-004-20240425 clang i386 buildonly-randconfig-005-20240425 clang i386 buildonly-randconfig-006-20240425 gcc i386 randconfig-001-20240425 clang i386 randconfig-002-20240425 clang i386 randconfig-003-20240425 clang i386 randconfig-004-20240425 gcc i386 randconfig-005-20240425 clang i386 randconfig-006-20240425 clang i386 randconfig-011-20240425 clang i386 randconfig-012-20240425 clang i386 randconfig-013-20240425 gcc i386 randconfig-014-20240425 gcc i386 randconfig-015-20240425 gcc i386 randconfig-016-20240425 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68kstmark2_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc mips lemote2f_defconfig gcc mips loongson1c_defconfig gcc mipsmaltaup_xpa_defconfig gcc mips pic32mzda_defconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openriscdefconfig gcc pariscallnoconfig gcc parisc defconfig gcc parisc64 alldefconfig gcc parisc64defconfig gcc powerpc allnoconfig gcc powerpc allyesconfig clang powerpc randconfig-003-20240425 clang powerpcsam440ep_defconfig gcc powerpc tqm8540_defconfig gcc
[kvalo-ath:pending] BUILD SUCCESS 1072be5562afc79e25b462b48619e1ddd80def50
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending branch HEAD: 1072be5562afc79e25b462b48619e1ddd80def50 wifi: ath10k: fake missing MSA_READY indicator elapsed time: 1460m configs tested: 128 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc axs101_defconfig gcc arc axs103_defconfig gcc arc defconfig gcc arc haps_hs_defconfig gcc arm allmodconfig gcc arm allnoconfig clang arm allyesconfig gcc arm collie_defconfig gcc arm defconfig clang arm randconfig-001-20240425 clang arm randconfig-002-20240425 clang arm randconfig-003-20240425 clang arm randconfig-004-20240425 clang arm s3c6400_defconfig gcc arm sp7021_defconfig gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang hexagon randconfig-001-20240425 clang hexagon randconfig-002-20240425 clang i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20240425 gcc i386 buildonly-randconfig-003-20240425 gcc i386 buildonly-randconfig-006-20240425 gcc i386 randconfig-004-20240425 gcc i386 randconfig-013-20240425 gcc i386 randconfig-014-20240425 gcc i386 randconfig-015-20240425 gcc i386 randconfig-016-20240425 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68kstmark2_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc mips lemote2f_defconfig gcc mips loongson1c_defconfig gcc mipsmaltaup_xpa_defconfig gcc mips pic32mzda_defconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openriscdefconfig gcc pariscallnoconfig gcc parisc defconfig gcc parisc64 alldefconfig gcc parisc64defconfig gcc powerpc allnoconfig gcc powerpc allyesconfig clang powerpc randconfig-003-20240425 clang powerpcsam440ep_defconfig gcc powerpc tqm8540_defconfig gcc riscvallmodconfig clang riscv allnoconfig gcc riscvallyesconfig clang riscv defconfig clang s390
Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
Conor Dooley writes: > On Thu, Apr 25, 2024 at 06:42:16PM +0300, Kalle Valo wrote: > >> Marc Gonzalez writes: >> >> > On 25/04/2024 11:42, Kalle Valo wrote: >> > >> >> Marc Gonzalez wrote: >> >> >> >>> Do you prefer: >> >>> >> >>> Option A = never waiting for the MSA_READY indicator for ANYONE >> >>> Option B = not waiting for the MSA_READY indicator when >> >>> qcom,no-msa-ready-indicator is defined >> >>> Option C = not waiting for the MSA_READY indicator for certain >> >>> platforms (based on root compatible) >> >>> Option D = some other solution not yet discussed >> >> >> >> After firmware-N.bin solution didn't work (sorry about that!) my >> >> preference is option B. >> > >> > Actually, Option B is this patch series. >> > Could you formally review it? >> >> I'm happy with this series and would take it to ath.git, just need an >> ack from DT maintainers: > > As far as I can tell, Krzysztof wanted a commit message update for > 1/3. That's my understanding as well, I assume Marc will submit v3. I marked this patchset as 'Changes Requested' in patchwork. > Usually this dts patch would go via the qcom dts tree, so presumably > there's a need for an Ack from Bjorn or Konrad? Thanks pointing this out. What I meant to say earlier that I'm happy to take patches 1-2 to ath.git but I prefer that patch 3 goes via qcom dts tree. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
On Thu, Apr 25, 2024 at 06:42:16PM +0300, Kalle Valo wrote: > Marc Gonzalez writes: > > > On 25/04/2024 11:42, Kalle Valo wrote: > > > >> Marc Gonzalez wrote: > >> > >>> Do you prefer: > >>> > >>> Option A = never waiting for the MSA_READY indicator for ANYONE > >>> Option B = not waiting for the MSA_READY indicator when > >>> qcom,no-msa-ready-indicator is defined > >>> Option C = not waiting for the MSA_READY indicator for certain > >>> platforms (based on root compatible) > >>> Option D = some other solution not yet discussed > >> > >> After firmware-N.bin solution didn't work (sorry about that!) my > >> preference is option B. > > > > Actually, Option B is this patch series. > > Could you formally review it? > > I'm happy with this series and would take it to ath.git, just need an > ack from DT maintainers: As far as I can tell, Krzysztof wanted a commit message update for 1/3. Usually this dts patch would go via the qcom dts tree, so presumably there's a need for an Ack from Bjorn or Konrad? > > https://patchwork.kernel.org/project/linux-wireless/patch/84f20fb5-5d48-419c-8eff-d7044afb8...@freebox.fr/ > > > Perhaps one thing I could do slightly differently is to NOT call > > ath10k_qmi_event_msa_ready() a second time if we DO receive the > > indicator later. > > Good point. And maybe add an ath10k_warn() message so that we notice if > there's a mismatch. > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches signature.asc Description: PGP signature
Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
Marc Gonzalez writes: > On 25/04/2024 11:42, Kalle Valo wrote: > >> Marc Gonzalez wrote: >> >>> Do you prefer: >>> >>> Option A = never waiting for the MSA_READY indicator for ANYONE >>> Option B = not waiting for the MSA_READY indicator when >>> qcom,no-msa-ready-indicator is defined >>> Option C = not waiting for the MSA_READY indicator for certain >>> platforms (based on root compatible) >>> Option D = some other solution not yet discussed >> >> After firmware-N.bin solution didn't work (sorry about that!) my >> preference is option B. > > Actually, Option B is this patch series. > Could you formally review it? I'm happy with this series and would take it to ath.git, just need an ack from DT maintainers: https://patchwork.kernel.org/project/linux-wireless/patch/84f20fb5-5d48-419c-8eff-d7044afb8...@freebox.fr/ > Perhaps one thing I could do slightly differently is to NOT call > ath10k_qmi_event_msa_ready() a second time if we DO receive the > indicator later. Good point. And maybe add an ath10k_warn() message so that we notice if there's a mismatch. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
On 25/04/2024 11:42, Kalle Valo wrote:
> Marc Gonzalez wrote:
>
>> Do you prefer:
>>
>> Option A = never waiting for the MSA_READY indicator for ANYONE
>> Option B = not waiting for the MSA_READY indicator when
>> qcom,no-msa-ready-indicator is defined
>> Option C = not waiting for the MSA_READY indicator for certain
>> platforms (based on root compatible)
>> Option D = some other solution not yet discussed
>
> After firmware-N.bin solution didn't work (sorry about that!) my
> preference is option B.
Actually, Option B is this patch series.
Could you formally review it?
Perhaps one thing I could do slightly differently is to NOT call
ath10k_qmi_event_msa_ready() a second time if we DO receive the
indicator later.
>> Dmitry has tested Option A on 5 platforms, where it does not induce
>> regressions.
>> I worked on msm8998, where Option A (or any equivalent) unbreaks WiFi.
>
> What do you mean here? Are you saying that option A works on all
> devices? I'm guessing I'm misunderstanding something.
No one serious would ever claim "this works on all devices".
Dmitry and I tested the following patch:
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
b/drivers/net/wireless/ath/ath10k/qmi.c
index 38e939f572a9e..fd9ac9717488a 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1040,6 +1040,8 @@ static void ath10k_qmi_driver_event_work(struct
work_struct *work)
switch (event->type) {
case ATH10K_QMI_EVENT_SERVER_ARRIVE:
ath10k_qmi_event_server_arrive(qmi);
+ printk(KERN_NOTICE "NOT WAITING FOR MSA_READY
INDICATOR");
+ ath10k_qmi_event_msa_ready(qmi);
break;
case ATH10K_QMI_EVENT_SERVER_EXIT:
ath10k_qmi_event_server_exit(qmi);
@@ -1048,7 +1050,7 @@ static void ath10k_qmi_driver_event_work(struct
work_struct *work)
ath10k_qmi_event_fw_ready_ind(qmi);
break;
case ATH10K_QMI_EVENT_MSA_READY_IND:
- ath10k_qmi_event_msa_ready(qmi);
+ printk(KERN_NOTICE "IGNORING ACTUAL MSA_READY
INDICATOR");
break;
default:
ath10k_warn(ar, "invalid event type: %d", event->type);
Dmitry tested several platforms:
> For reference, I tested this patch on sdm845 (db845c), qcm2290 aka
> qrb2210 (rb1), sm6115 aka qrb4210 (rb2) and sm8150 platforms.
> I was not able to fully test it on sda660, modem crashes without this
> patch (there is no MSA_READY indication) and with the patch applied
> the device hangs, most likely because of the IOMMU or clocking issue.
I tested on apq8098 (msm8998 sibling).
Patch makes adapter work on my msm8998 platform.
Regards
Re: [PATCH 1/3] wifi: ath10k: populate board data for WCN3990
Dmitry Baryshkov wrote:
> Specify board data size (and board.bin filename) for the WCN3990
> platform.
>
> Reported-by: Yongqin Liu
> Fixes: 03a72288c546 ("ath10k: wmi: add hw params entry for wcn3990")
> Signed-off-by: Dmitry Baryshkov
> Signed-off-by: Kalle Valo
3 patches applied to ath-next branch of ath.git, thanks.
f1f1b5b055c9 wifi: ath10k: populate board data for WCN3990
de0ff4613363 wifi: ath10k: drop chip-specific board data file name
3ebae49bbc12 wifi: ath10k: drop fw.eboard file name
--
https://patchwork.kernel.org/project/linux-wireless/patch/20240130-wcn3990-board-fw-v1-1-738f7c19a...@linaro.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
Eric Park writes: > Resending as I forgot to CC the mailing list, sorry! I've added some > more info since the last email. Thanks. Let's keep the discussion on the list so that others can join. > On 2024-03-11 11:21, Kalle Valo wrote: >> But with modern CPUs I would have still expected software encryption to >> be faster than 20 Mbps so the chances are it can be something else as >> well. > > I just checked and the laptop has an i5-5200U, but I'm not sure if > it's the bottleneck. I ran a speedtest while monitoring the load and > the CPU usage never went past 20-50% or so. This depends how you measured CPU usage so I would not make any conclusions from this yet. I also don't know what's the best way to measure CPU usage from kernel driver point of view. >> That's a user space decision and depends on what connection manager you >> use. > > That's the weird part, for some reason I can't get it to force-connect > via WPA2-PSK. I've tried KDE's network configuration and `nmtui`, but > when I connect to the network it seems like it tries to negotiate with > WPA2-PSK first and then "upgrades" to WPA3-SAE. Or at least that's how > it appears in the network details dropdown if I click on the chevron > next to the Wi-Fi SSID. I do not use Network Manager or other connection managers when testing. It's much more reliable to use wpasupplicant directly and you get full control. I usually create a custom config file and then start the supplicant manually. Some pointers: https://wiki.archlinux.org/title/wpa_supplicant https://w1.fi/cgit/hostap/plain/wpa_supplicant/README https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.conf -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi
Marc Gonzalez writes: > On 04/04/2024 17:28, Kalle Valo wrote: > >> Marc Gonzalez wrote: >> >>> On 04/04/2024 13:57, Kalle Valo wrote: >>> Dmitry Baryshkov wrote: > I'd say, we should take a step back and actually verify how this was > handled in the vendor kernel. One comment related to this: usually vendor driver and firmware branches go "hand in hand", meaning that a version of driver supports only one specific firmware branch. And there can be a lot of branches. So even if one branch might have a check for something specific, there are no guarantees what the other N+1 branches do :/ >>> >>> The consequences and ramifications of the above comment are not clear to me. >>> >>> Does this mean: >>> "It is pointless to analyze a given version (or even several versions) >>> of the vendor driver downstream, because there are exist a large number >>> of variations of the code." ? >> >> I was trying to say that because the design philosophy between vendor >> drivers and upstream drivers is very different, we can't 100% trust >> vendor drivers. It's a very good idea to check what vendor drivers do >> but we just need to be careful before making any conclusions. Testing >> real hardware (and corresponding firmware) is the most reliable way to >> know how different products/firmware work, unfortunately. >> >>> And thus, "it is nonsensical to try to "align" the mainline driver to >>> "the" vendor driver, as there is no single "vendor driver"" ? >> >> No no, I'm not saying that. I have suffered this "N+1 different firmware >> branches behaving slighly differently" problem since ath6kl days so for >> me this is business as usual, sadly. I'm sure we can find a solution for >> ath10k. > > Hello Kalle, > > I can spin a v3, no problem. > > Do you prefer: > > Option A = never waiting for the MSA_READY indicator for ANYONE > Option B = not waiting for the MSA_READY indicator when > qcom,no-msa-ready-indicator is defined > Option C = not waiting for the MSA_READY indicator for certain > platforms (based on root compatible) > Option D = some other solution not yet discussed After firmware-N.bin solution didn't work (sorry about that!) my prerence is option B. > Dmitry has tested Option A on 5 platforms, where it does not induce > regressions. > I worked on msm8998, where Option A (or any equivalent) unbreaks WiFi. What do you mean here? Are you saying that option A works on all devices? I'm guessing I'm misunderstanding something. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
