Re: [PATCH] wifi: ath10k: fix the stack frame size warning in ath10k_hw_scan
Miaoqing Pan wrote: > Fix the following W=1 kernel build warning: > > drivers/net/wireless/ath/ath10k/mac.c: In function ‘ath10k_hw_scan’: > drivers/net/wireless/ath/ath10k/mac.c:6468:1: warning: the frame size of 1064 > bytes is larger than 1024 bytes [-Wframe-larger-than=] > > Compile tested only. > > Signed-off-by: Miaoqing Pan > Acked-by: Jeff Johnson > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. acf8304b58e8 wifi: ath10k: fix the stack frame size warning in ath10k_hw_scan -- https://patchwork.kernel.org/project/linux-wireless/patch/20240830015649.1083758-1-quic_miaoq...@quicinc.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches https://docs.kernel.org/process/submitting-patches.html
Re: [PATCH] wifi: ath10k: fix the stack frame size warning in ath10k_remain_on_channel
Miaoqing Pan wrote: > Fix the following W=1 kernel build warning: > > drivers/net/wireless/ath/ath10k/mac.c: In function ‘ath10k_remain_on_channel’: > drivers/net/wireless/ath/ath10k/mac.c:7980:1: warning: the frame size of 1064 > bytes is larger than 1024 bytes [-Wframe-larger-than=] > > Compile tested only. > > Signed-off-by: Miaoqing Pan > Acked-by: Jeff Johnson > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. c4c074d3fddc wifi: ath10k: fix the stack frame size warning in ath10k_remain_on_channel -- https://patchwork.kernel.org/project/linux-wireless/patch/20240830015349.1083226-1-quic_miaoq...@quicinc.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches https://docs.kernel.org/process/submitting-patches.html
Re: [PATCH 1/2] wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1
Baochen Qiang wrote:
> In supported_vht_mcs_rate_nss1, the rate for MCS9 & VHT20 is defined as
> {780, 867}, this does not align with firmware's definition and therefore
> fails the verification in ath10k_mac_get_rate_flags_vht():
>
> invalid vht params rate 960 100kbps nss 1 mcs 9
>
> Change it to {865, 960} to align with firmware, so this issue could be
> fixed.
>
> Since ath10k_hw_params::supports_peer_stats_info is enabled only for
> QCA6174, this change does not affect other chips.
>
> Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1
>
> Fixes: 3344b99d69ab ("ath10k: add bitrate parse for peer stats info")
> Reported-by: Paul Menzel
> Closes:
> https://lore.kernel.org/lkml/fba24cd3-4a1e-4072-8585-840227278...@molgen.mpg.de/
> Signed-off-by: Baochen Qiang
> Acked-by: Jeff Johnson
> Signed-off-by: Kalle Valo
2 patches applied to ath-next branch of ath.git, thanks.
d50886b27850 wifi: ath10k: fix invalid VHT parameters in
supported_vht_mcs_rate_nss1
52db16ec5bae wifi: ath10k: fix invalid VHT parameters in
supported_vht_mcs_rate_nss2
--
https://patchwork.kernel.org/project/linux-wireless/patch/20240711020344.98040-2-quic_bqi...@quicinc.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
https://docs.kernel.org/process/submitting-patches.html
Re: New staging repos for ath1*k firmware
Sven Eckelmann writes: > On Thursday, 7 March 2024 09:39:26 CEST Robert Marko wrote: >> Can I please ask for IPQ6018 firmware to be updated to 2.9.0.1 as well? >> > > I've asked them via their support platform. They closed the ticket after Jeff > uploaded the 2.7.0.1 firmware (which was given to him by the firmware team). > > I will ask again... > > (Btw. thanks to Jeff and Kalle for managing the new firmware repositories - I > just hope that you get better input from the firmware teams) Thanks, this is not easy but we are trying to improve. It's just that the progress is so slow that it's really frustrating. As there are so many different branches I have lost track, do you have a list of missing firmware updates? We could try to push for updates on our own end as well. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: ath-next-20240909
Jeff Johnson wrote: > The following changes since commit ae98f5c9fd8ba84cd408b41faa77e65bf1b4cdfa: > > Merge tag 'ath-next-20240812' of > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath (2024-08-13 12:58:32 > +0300) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git > tags/ath-next-20240909 > > for you to fetch changes up to 02f454f9aa6255d99611d6a4e37edd08812878df: > > wifi: ath12k: Avoid -Wflex-array-member-not-at-end warnings (2024-09-05 > 19:20:21 +0300) > > > ath.git patches for v6.12 > > This is once again a fairly light pull request since ath12k is still > working on MLO-related changes, and the other drivers are mostly in > maintenance mode. > > ath12k > > * Fix a frame-larger-than warning seen with debug builds > * Fix flex-array-member-not-at-end warnings > > ath11k > > * Fix flex-array-member-not-at-end warnings > > ath9k > > * Fix a syzbot-reported issue on USB-based devices > > > Gustavo A. R. Silva (2): > wifi: ath11k: Avoid -Wflex-array-member-not-at-end warnings > wifi: ath12k: Avoid -Wflex-array-member-not-at-end warnings > > Miaoqing Pan (1): > wifi: ath12k: fix the stack frame size warning in ath12k_mac_op_hw_scan > > Toke Høiland-Jørgensen (1): > wifi: ath9k_htc: Use __skb_set_length() for resetting urb before > resubmit > > drivers/net/wireless/ath/ath11k/core.h | 8 - > drivers/net/wireless/ath/ath11k/dp.h | 23 -- > drivers/net/wireless/ath/ath12k/core.h | 8 - > drivers/net/wireless/ath/ath12k/dp.h | 12 --- > drivers/net/wireless/ath/ath12k/mac.c| 54 > ++-- > drivers/net/wireless/ath/ath9k/hif_usb.c | 6 ++-- > 6 files changed, 46 insertions(+), 65 deletions(-) Pulled, thanks. fe57beb026ef Merge tag 'ath-next-20240909' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath -- https://patchwork.kernel.org/project/linux-wireless/patch/13914e4d-92d4-4ccd-a7d5-86c5a1742...@quicinc.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: failed to remove key (0, ce:ce:1e:27:bb:e0) from hardware (-110) (ETIMEDOUT)
Paul Menzel writes: > Am 04.09.24 um 16:48 schrieb Kalle Valo: >> Paul Menzel writes: > >>> Linux 6.11-rc6+ logged the warning below when resuming from ACPI S3 >>> (or unloading and loading the `ath10k_core`/`ath10k_pci` modules) >>> having been connected to an AVM network: >>> >>> wlp58s0: failed to remove key (0, ce:ce:1e:27:bb:e0) from hardware >>> (-110) >>> >>> Error code 110 is the value for ETIMEDOUT. I saw James patch [1], and >>> applied it, and the error is still there (as expected). >>> >>> Can the warning be improved so the user know, which component is at fault? >> The warning comes from mac80211 and it already contains your network >> interface name (wlp58s0). What else would you want to see? > > As an ignorant user, I do not know what to do with the warning. I’d > like to see a suggestion how to get rid of the warning. Maybe: > > wlp58s0: failed to remove key (0, ce:ce:1e:27:bb:e0) from hardware > in X s (-110), please report it to the vendor firmware The warning can come due to different reasons in different drivers, it's not really easy to identify what the user should do. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: failed to remove key (0, ce:ce:1e:27:bb:e0) from hardware (-110) (ETIMEDOUT)
Paul Menzel writes: > Dear Linux folks, > > > Linux 6.11-rc6+ logged the warning below when resuming from ACPI S3 > (or unloading and loading the `ath10k_core`/`ath10k_pci` modules) > having been connected to an AVM network: > > wlp58s0: failed to remove key (0, ce:ce:1e:27:bb:e0) from hardware > (-110) > > Error code 110 is the value for ETIMEDOUT. I saw James patch [1], and > applied it, and the error is still there (as exepected). > > Can the warning be improved so the user know, which component is at fault? The warning comes from mac80211 and it already contains your network interface name (wlp58s0). What else would you want to see? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches https://docs.kernel.org/process/submitting-patches.html
Re: pull-request: ath-current-20240903
Jeff Johnson wrote: > The following changes since commit 38055789d15155109b41602ad719d770af507030: > > wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850 > (2024-08-05 12:28:07 +0300) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git > tags/ath-current-20240903 > > for you to fetch changes up to 2f833e8948d6c88a3a257d4e426c9897b4907d5a: > > Revert "wifi: ath11k: support hibernation" (2024-09-02 19:33:00 +0300) > > > ath.git patches for v6.11-rc7 > > We have three patch which address two issues in the ath11k driver > which should be addressed for 6.11-rc7: > > One patch fixes a NULL pointer dereference while parsing transmit > power envelope (TPE) information, and the other two patches revert the > hibernation support since it is interfering with suspend on some > platforms. Note the cause of the suspend wakeups is still being > investigated, and it is hoped this can be addressed and hibernation > support can be restored in the near future. > > > Baochen Qiang (3): > wifi: ath11k: fix NULL pointer dereference in > ath11k_mac_get_eirp_power() > Revert "wifi: ath11k: restore country code during resume" > Revert "wifi: ath11k: support hibernation" > > drivers/net/wireless/ath/ath11k/ahb.c | 4 +- > drivers/net/wireless/ath/ath11k/core.c | 115 > + > drivers/net/wireless/ath/ath11k/core.h | 4 -- > drivers/net/wireless/ath/ath11k/hif.h | 12 +--- > drivers/net/wireless/ath/ath11k/mac.c | 1 + > drivers/net/wireless/ath/ath11k/mhi.c | 12 +--- > drivers/net/wireless/ath/ath11k/mhi.h | 3 +- > drivers/net/wireless/ath/ath11k/pci.c | 44 ++--- > drivers/net/wireless/ath/ath11k/qmi.c | 2 +- > 9 files changed, 49 insertions(+), 148 deletions(-) Pulled, thanks. e88b9ed3e03a Merge tag 'ath-current-20240903' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath -- https://patchwork.kernel.org/project/linux-wireless/patch/8a9375eb-3205-4a78-a8c1-bd85df106...@quicinc.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches https://docs.kernel.org/process/submitting-patches.html
Re: ath10k usb support status
Moro, Riku Voipio writes: > I note drivers/net/wireless/ath/ath10k/usb.c comes with the warning: > > /* TODO: remove this once USB support is fully implemented */ > ath10k_warn(ar, "Warning: ath10k USB support is incomplete, don't expect > anything to work!\n"); > > Is this still the state? The state USB support in ath10k is unclear for me and I have not personally tested it for years, I would recommend not to use it for anything serious. > If so, Is there alternative USB-connected chipset with good mainline support? It's best to ask this in linux-wireless list. But Realtek drivers have seen a lot of development recently and they do have USB devices so that is something to look at. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath10k "failed to install key for vdev 0 peer : -110"
James Prestwood writes: > On 8/15/24 7:03 AM, Kalle Valo wrote: >> James Prestwood writes: >> >>> Hi, >>> >>> So I have no resolution to this (trying to get the AP vendor to chase >>> it down), but I'm toying with the idea of trying to work around >>> whatever issue the AP is having when this occurs. The only thing I can >>> think of is that there is a 3 second delay between the authentication >>> and reassociation, and perhaps this is causing some timeout in the AP >>> and in turn the deauth. >>> >>> I'm wondering how long it should take to add/remove a key from the >>> firmware? 3 seconds seems very long, and I question if this timeout is >>> really necessary or was just chosen arbitrarily? Is this something >>> that could be lowered down to e.g. 1 second without negative impacts? >>> The code in question is in ath10k_install_key: >>> >>> ret = ath10k_send_key(arvif, key, cmd, macaddr, flags); >>> if (ret) >>> return ret; >>> >>> time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ); >>> if (time_left == 0) >>> return -ETIMEDOUT; >> I can't remember anymore but I'm guessing the 3s delay was chosen >> arbitrarily just to be on the safe side and not get unnecessary >> timeouts. > > Thanks, I have reduced this to 1 second and have had it running on a > client for ~19 hours. Still am seeing the timeouts, but no more than > prior. And even with the timeouts the roams are successful. > > After doing more looking in the spec I did see that there is > dot11ReassociationDeadline which may be coming into play here. Of > course these APs aren't advertising any TIE or even support FT > resource requests that so its impossible to know for sure, and hostapd > AFAICT doesn't enforce any deadlines even if you set it... But in any > case the timeout reduction is helping immensely and avoiding a > disconnect. Yeah, reducing the time out might a good option. 3s feels like overkill, especially if 1s timeout passes your tests. But I do wonder what's the root cause here. Are you saying that SET_KEY always works for you? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: linux-next: manual merge of the ath-next tree with the ath tree
Stephen Rothwell writes:
> Hi all,
>
> On Thu, 8 Aug 2024 10:43:48 +1000 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the ath-next tree got a conflict in:
>>
>> drivers/net/wireless/ath/ath12k/hw.c
>>
>> between commit:
>>
>> 38055789d151 ("wifi: ath12k: use 128 bytes aligned iova in transmit path
>> for WCN7850")
>>
>> from the ath tree and commit:
>>
>> 8be12629b428 ("wifi: ath12k: restore ASPM for supported hardwares only")
>>
>> from the ath-next tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging. You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
>> diff --cc drivers/net/wireless/ath/ath12k/hw.c
>> index 7b0b6a7f4701,76c0e07a88de..
>> --- a/drivers/net/wireless/ath/ath12k/hw.c
>> +++ b/drivers/net/wireless/ath/ath12k/hw.c
>> @@@ -925,7 -925,7 +925,9 @@@ static const struct ath12k_hw_params at
>> .acpi_guid = NULL,
>> .supports_dynamic_smps_6ghz = true,
>>
>> + .iova_mask = 0,
>> ++
>> +.supports_aspm = false,
>> },
>> {
>> .name = "wcn7850 hw2.0",
>> @@@ -1003,7 -1003,7 +1005,9 @@@
>> .acpi_guid = &wcn7850_uuid,
>> .supports_dynamic_smps_6ghz = false,
>>
>> + .iova_mask = ATH12K_PCIE_MAX_PAYLOAD_SIZE - 1,
>> ++
>> +.supports_aspm = true,
>> },
>> {
>> .name = "qcn9274 hw2.0",
>> @@@ -1077,7 -1077,7 +1081,9 @@@
>> .acpi_guid = NULL,
>> .supports_dynamic_smps_6ghz = true,
>>
>> + .iova_mask = 0,
>> ++
>> +.supports_aspm = false,
>> },
>> };
>>
>
> This is now a conflict between the wireless-next tree and the ath tree.
Thanks. The plan is that the network maintainers will fix this once the
commits "meet" in net-next. We are trying to avoid unnessary merges.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath10k "failed to install key for vdev 0 peer : -110"
James Prestwood writes: > Hi, > > So I have no resolution to this (trying to get the AP vendor to chase > it down), but I'm toying with the idea of trying to work around > whatever issue the AP is having when this occurs. The only thing I can > think of is that there is a 3 second delay between the authentication > and reassociation, and perhaps this is causing some timeout in the AP > and in turn the deauth. > > I'm wondering how long it should take to add/remove a key from the > firmware? 3 seconds seems very long, and I question if this timeout is > really necessary or was just chosen arbitrarily? Is this something > that could be lowered down to e.g. 1 second without negative impacts? > The code in question is in ath10k_install_key: > > ret = ath10k_send_key(arvif, key, cmd, macaddr, flags); > if (ret) > return ret; > > time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ); > if (time_left == 0) > return -ETIMEDOUT; I can't remember anymore but I'm guessing the 3s delay was chosen arbitrarily just to be on the safe side and not get unnecessary timeouts. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PULL linux-firmware] ath11k and ath12k firmware 20240813
Hi, Here's a pull request for ath11k and ath12k. We have new ath11k hardware QCA2066 hw2.1 and usual smaller updates. Please let me know if there are any problems. Kalle The following changes since commit 594600762910b4bbe8a88d0dc6495521366c880c: Merge branch 'vpu' into 'main' (2024-08-09 13:02:09 +) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ath/linux-firmware.git ath-20240813 for you to fetch changes up to 82318c966fd1af87044299d34611751c76f70927: ath12k: WCN7850 hw2.0: update board-2.bin (2024-08-13 19:36:13 +0300) ---- Kalle Valo (6): ath11k: IPQ5018 hw1.0: update to WLAN.HK.2.6.0.1-01291-QCAHKSWPL_SILICONZ-1 ath11k: QCA2066 hw2.1: add board-2.bin ath11k: QCA2066 hw2.1: add to WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.3 ath11k: WCN6855 hw2.0: update board-2.bin ath11k: WCN6855 hw2.0: update to WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 ath12k: WCN7850 hw2.0: update board-2.bin WHENCE |9 +- ath11k/IPQ5018/hw1.0/m3_fw.b01 | Bin 136 -> 136 bytes ath11k/IPQ5018/hw1.0/m3_fw.b02 | Bin 262144 -> 262144 bytes ath11k/IPQ5018/hw1.0/m3_fw.mdt | Bin 284 -> 284 bytes ath11k/IPQ5018/hw1.0/q6_fw.b00 | Bin 532 -> 532 bytes ath11k/IPQ5018/hw1.0/q6_fw.b01 | Bin 520 -> 520 bytes ath11k/IPQ5018/hw1.0/q6_fw.b02 | Bin 7552 -> 7552 bytes ath11k/IPQ5018/hw1.0/q6_fw.b04 | Bin 86788 -> 86788 bytes ath11k/IPQ5018/hw1.0/q6_fw.b08 | Bin 4096 -> 4096 bytes ath11k/IPQ5018/hw1.0/q6_fw.b09 | Bin 2330624 -> 2334720 bytes ath11k/IPQ5018/hw1.0/q6_fw.b10 | Bin 269028 -> 269220 bytes ath11k/IPQ5018/hw1.0/q6_fw.b11 | Bin 99436 -> 99456 bytes ath11k/IPQ5018/hw1.0/q6_fw.b13 | Bin 7024 -> 7072 bytes ath11k/IPQ5018/hw1.0/q6_fw.mdt | Bin 1052 -> 1052 bytes ath11k/QCA2066/hw2.1/Notice.txt | 3658 ++ ath11k/QCA2066/hw2.1/amss.bin| Bin 0 -> 5349376 bytes ath11k/QCA2066/hw2.1/board-2.bin | Bin 0 -> 685144 bytes ath11k/QCA2066/hw2.1/m3.bin | Bin 0 -> 266684 bytes ath11k/WCN6855/hw2.0/amss.bin| Bin 4988928 -> 4988928 bytes ath11k/WCN6855/hw2.0/board-2.bin | Bin 6308684 -> 6429240 bytes ath11k/WCN6855/hw2.0/m3.bin | Bin 266684 -> 266684 bytes ath12k/WCN7850/hw2.0/board-2.bin | Bin 382856 -> 1897968 bytes 22 files changed, 3665 insertions(+), 2 deletions(-) create mode 100644 ath11k/QCA2066/hw2.1/Notice.txt create mode 100644 ath11k/QCA2066/hw2.1/amss.bin create mode 100644 ath11k/QCA2066/hw2.1/board-2.bin create mode 100644 ath11k/QCA2066/hw2.1/m3.bin
Re: pull-request: ath-next-20240812
Jeff Johnson wrote: > The following changes since commit c1cacb01f35589bd41360cdb7535afc792c08a7c: > > Merge tag 'ath-next-20240702' of > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath (2024-07-03 16:57:16 > +0300) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git > tags/ath-next-20240812 > > for you to fetch changes up to 89fbe672bd0e5e5c39600fcc7a3bca0b8a212d23: > > Revert "wifi: ath9k: use devm for request_irq()" (2024-08-10 10:21:58 +0300) > > > ath.git patches for v6.12 > > This is a fairly light pull request since ath12k is still working on > MLO-related changes, and the other drivers are mostly in maintenance > mode with a few cleanups and bug fixes. > > Major changes: > > ath12k > > * DebugFS support for transmit DE stats > * Make ASPM support hardware-dependent > * Align BSS Channel information command and message with firmware > > ath11k > > * Use work queue for beacon tx events > > ath9k > > * Use devm for gpio_request_one > * Use unmanaged PCI functions in ath9k_pci_owl_loader() > > > Aditya Kumar Singh (1): > wifi: ath12k: restore ASPM for supported hardwares only > > Baochen Qiang (1): > wifi: ath12k: fix invalid AMPDU factor calculation in > ath12k_peer_assoc_h_he() > > Dinesh Karthikeyan (1): > wifi: ath12k: Support Transmit DE stats > > Dmitry Kandybka (1): > wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats() > > Heiner Kallweit (1): > wifi: ath9k: use unmanaged PCI functions in ath9k_pci_owl_loader > > Kang Yang (1): > wifi: ath11k: use work queue to process beacon tx event > > Karthikeyan Periyasamy (2): > wifi: ath12k: fix array out-of-bound access in SoC stats > wifi: ath11k: fix array out-of-bound access in SoC stats > > P Praneesh (2): > wifi: ath12k: fix BSS chan info request WMI command > wifi: ath12k: match WMI BSS chan info structure with firmware definition > > Rosen Penev (2): > wifi: ath9k: use devm for request_irq() > wifi: ath9k: use devm for gpio_request_one() > > Thorsten Blum (1): > wifi: ath9k: Use swap() to improve ath9k_hw_get_nf_hist_mid() > > Toke Høiland-Jørgensen (2): > wifi: ath9k: Remove error checks when creating debugfs entries > Revert "wifi: ath9k: use devm for request_irq()" > > drivers/net/wireless/ath/ath11k/core.h | 1 + > drivers/net/wireless/ath/ath11k/dp_rx.c| 2 +- > drivers/net/wireless/ath/ath11k/mac.c | 12 + > drivers/net/wireless/ath/ath11k/wmi.c | 4 +- > .../net/wireless/ath/ath12k/debugfs_htt_stats.c| 354 > + > .../net/wireless/ath/ath12k/debugfs_htt_stats.h| 126 > drivers/net/wireless/ath/ath12k/dp_rx.c| 2 +- > drivers/net/wireless/ath/ath12k/hw.c | 6 + > drivers/net/wireless/ath/ath12k/hw.h | 1 + > drivers/net/wireless/ath/ath12k/mac.c | 5 +- > drivers/net/wireless/ath/ath12k/pci.c | 3 +- > drivers/net/wireless/ath/ath12k/wmi.c | 1 + > drivers/net/wireless/ath/ath12k/wmi.h | 3 +- > .../net/wireless/ath/ath9k/ath9k_pci_owl_loader.c | 8 +- > drivers/net/wireless/ath/ath9k/calib.c | 7 +- > drivers/net/wireless/ath/ath9k/debug.c | 6 +- > drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 2 - > drivers/net/wireless/ath/ath9k/hw.c| 6 +- > 18 files changed, 521 insertions(+), 28 deletions(-) Pulled, thanks. ae98f5c9fd8b Merge tag 'ath-next-20240812' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath -- https://patchwork.kernel.org/project/linux-wireless/patch/9ee38166-782b-409d-a2df-e2cee6e2a...@quicinc.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: ath-current-20240812
Jeff Johnson wrote: > The following changes since commit de9c2c66ad8e787abec7c9d7eff4f8c3cdd28aed: > > Linux 6.11-rc2 (2024-08-04 13:50:53 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git > tags/ath-current-20240812 > > for you to fetch changes up to 38055789d15155109b41602ad719d770af507030: > > wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850 > (2024-08-05 12:28:07 +0300) > > > ath.git patch for v6.11 > > We have a single patch for the next 6.11-rc which introduces a > workaround to ath12k which addresses a WCN7850 hardware issue that > prevents proper operation with unaligned transmit buffers. > > > Baochen Qiang (1): > wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850 > > drivers/net/wireless/ath/ath12k/dp_tx.c | 72 > + > drivers/net/wireless/ath/ath12k/hw.c| 6 +++ > drivers/net/wireless/ath/ath12k/hw.h| 4 ++ > drivers/net/wireless/ath/ath12k/mac.c | 1 + > 4 files changed, 83 insertions(+) Pulled, thanks. e37a9184f270 Merge tag 'ath-current-20240812' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath -- https://patchwork.kernel.org/project/linux-wireless/patch/7c3b295d-3d5e-40ee-ac33-c92669f29...@quicinc.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [question] is it possible to enable monitor mode /packet injection on wcn3990
MOHAMMAD RASIM writes: >> On 12 Aug 2024, at 10:02 AM, Kalle Valo wrote: >> >> + ath10k list >> >>> I have a device that has the wcn3990 wifi chip that uses the >>> ath10k_snoc driver, i tried to put it in monitor mode, the "set >>> monitor" mode command succeed but can't get any scanning working after >>> that, does the chip support such mode?has anyone tried monitor mode >>> with this chip or other snoc chips? >> >> I doubt that WCN3990 firmware supports monitor mode, though just >> guessing here. > > Some people has got monitor mode working under android ( different > driver, qcacld-2.0, and qcacld-3.0) with these kind of chips: > https://github.com/kimocoder/qualcomm_android_monitor_mode/ > > > Some older chips (wcn3680 think) even supported packet injection(using > the older qcacld-2.0 driver). > > Commits in the newer qcacld-3.0 driver (that supported the wcn3990) > did contain hints that monitor mode and packet injection should work. > > So maybe the firmware does support it? Maybe it does then, I don't know really. My response was just based on my past experiences with mobile chipsets. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [question] is it possible to enable monitor mode /packet injection on wcn3990
+ ath10k list > I have a device that has the wcn3990 wifi chip that uses the > ath10k_snoc driver, i tried to put it in monitor mode, the "set > monitor" mode command succeed but can't get any scanning working after > that, does the chip support such mode?has anyone tried monitor mode > with this chip or other snoc chips? I doubt that WCN3990 firmware supports monitor mode, though just guessing here. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: linux-next: manual merge of the ath-next tree with the ath tree
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the ath-next tree got a conflict in:
>
> drivers/net/wireless/ath/ath12k/hw.c
>
> between commit:
>
> 38055789d151 ("wifi: ath12k: use 128 bytes aligned iova in transmit
> path for WCN7850")
>
> from the ath tree and commit:
>
> 8be12629b428 ("wifi: ath12k: restore ASPM for supported hardwares only")
>
> from the ath-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks, the fix looks correct to me.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: Problem with driver ath10k_pci
SALVATORE BUONO writes: > Good morning, there is a problem with this driver with new version of > ubuntu, since before I update to 24.04 it works correctly, but now it does > not work anymore after sleep/suspension. It disconnects and I tried a lot > of commands to restart the wifi module but it does not work. This is the > discussion on ubuntu forum, but no solution is found. Can you fix it? > > > *Salvatore Buono* > salvatore@salvatore-Inspiron-5515:~$ sudo dmesg | grep ath10k > [3.509206] ath10k_pci :02:00.0: enabling device ( -> 0002) > [3.511043] ath10k_pci :02:00.0: pci irq msi oper_irq_mode 2 irq_mode > 0 reset_mode 0 > [3.734071] ath10k_pci :02:00.0: qca6174 hw3.2 target 0x0503 > chip_id 0x00340aff sub 1028:0310 > [3.734081] ath10k_pci :02:00.0: kconfig debug 0 debugfs 1 tracing 1 > dfs 0 testmode 0 > [3.734432] ath10k_pci :02:00.0: firmware ver WLAN.RM.4.4.1-00309- api > 6 features wowlan,ignore-otp,mfp crc32 0793bcf2 > [3.799439] ath10k_pci :02:00.0: board_file api 2 bmi_id N/A crc32 > d2863f91 > [3.881223] ath10k_pci :02:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal > otp max-sta 32 raw 0 hwcrypto 1 > [5.804589] ath10k_pci :02:00.0 wlp2s0: renamed from wlan0 > [ 394.964239] ath10k_pci :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT > domain=0x000b address=0xfb294f50 flags=0x0070] > [ 402.843038] ath10k_pci :02:00.0: pci irq msi oper_irq_mode 2 irq_mode > 0 reset_mode 0 > [ 403.045772] ath10k_pci :02:00.0: qca6174 hw3.2 target 0x0503 > chip_id 0x00340aff sub 1028:0310 > [ 403.045788] ath10k_pci :02:00.0: kconfig debug 0 debugfs 1 tracing 1 > dfs 0 testmode 0 > [ 403.046353] ath10k_pci :02:00.0: firmware ver WLAN.RM.4.4.1-00309- api > 6 features wowlan,ignore-otp,mfp crc32 0793bcf2 > [ 403.110616] ath10k_pci :02:00.0: board_file api 2 bmi_id N/A crc32 > d2863f91 > [ 403.197531] ath10k_pci :02:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal > otp max-sta 32 raw 0 hwcrypto 1 > [ 403.259722] ath10k_pci :02:00.0 wlp2s0: renamed from wlan0 > [ 418.545075] ath10k_pci :02:00.0: timed out waiting peer stats info > [ 423.537127] ath10k_pci :02:00.0: wmi command 90113 timeout, restarting > hardware > [ 423.537147] ath10k_pci :02:00.0: could not request stats (-11) > [ 423.549132] ath10k_pci :02:00.0: could not request peer stats info: > -108 > [ 423.559691] ath10k_pci :02:00.0: failed to read hi_board_data address: > -16 > [ 426.587606] ath10k_pci :02:00.0: failed to receive initialized event > from target: > [ 429.603807] ath10k_pci :02:00.0: failed to receive initialized event > from target: > [ 429.603824] ath10k_pci :02:00.0: failed to wait for target init: -110 > [ 429.606647] ath10k_pci :02:00.0: failed to delete WMI vdev 1: -108 > [ 429.606657] ath10k_pci :02:00.0: failed to set 2g txpower 46: -108 > [ 429.606661] ath10k_pci :02:00.0: failed to setup tx power 23: -108 > [ 429.606664] ath10k_pci :02:00.0: failed to recalc tx power: -108 > [ 429.606855] ath10k_pci :02:00.0: failed to flush transmit queue (skip > 1 ar-state 2): 5000 > [ 429.606898] ath10k_pci :02:00.0: failed to flush transmit queue (skip > 1 ar-state 2): 5000 You need to report this to Ubuntu. We don't support distro kernels, only vanilla kernel.org releases. Adding also ath10k list. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [REGRESSION] ath10k: failed to flush transmit queue
Felix Fietkau writes: > On 12.07.24 04:23, Cedric Veilleux wrote: > >> AP mode. >> Both 2.4 and 5ghz channels. >> Using WLE600VX (QCA986x/988x), we are seeing the following errors in >> kernel logs: >> [12978.022077] ath10k_pci :04:00.0: failed to flush transmit >> queue >> (skip 0 ar-state 1): 0 >> [13343.069189] ath10k_pci :04:00.0: failed to flush transmit queue >> (skip 0 ar-state 1): 0 >> They are somewhat random but frequent. Can happen once a day or many >> times per hour. >> They are associated with 3-4 seconds of radio silence. Full packet >> loss. Then everything resumes normally, STA are still associated and >> traffic resumes. >> I have tested with major kernel versions: >> 6.1.97: stable (tested for many days on 10+ access points) >> 6.2.16: stable (tested for few hours single machine) >> 6.3.13: stable (tested for few hours single machine) >> 6.4.16: unstable (we have errors within an hour) >> 6.5.13: unstable (we have errors within an hour) >> 6.6.39: unstable (we have errors within an hour) >> 6.7.12: unstable (we have errors within an hour) >> 6.8.10: unstable (we have errors within an hour) >> 6.9.7: unstable (we have errors within an hour) >> From these tests I believe something changed in 6.4 series causing >> instabilities and the dreaded "failed to flush transmit queue" error. >> This is a custom linux distribution. Only change is the kernel. All >> other packages are same versions. Everything rebuilt from source using >> bitbake/yocto. Same linux-firmware files. > > I'm pretty sure it's caused by this commit: > > commit 0b75a1b1e42e07ae84e3a11d2368b418546e2bec > Author: Johannes Berg > Date: Fri Mar 31 16:59:16 2023 +0200 > > wifi: mac80211: flush queues on STA removal > > I guess somebody needs to look into making the queue flush on ath10k > more reliable (or even better, implement a more lightweight .flush_sta > op). > > I don't have time to do the work myself, but hopefully this > information could help somebody else take care of it. Adding ath10k list so that everyone see this. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Baochen Qiang writes: >>> Checked with firmware team and just know that, the TX rate info is >>> generated by firmware directly but for RX rate it is from phy side. >>> From firmware TX rate generation code seems NSS 3 is an impossible >>> value, so it might be an RX rate generated by phy side. But I could >>> not tell for now since the log is not complete. Paul, could you >>> enable full ath10k log and try to reproduce? With full log we can >>> check whether it is a RX rate issue, >> >> Please tell me how I enable full logging. > > once boot, first unload ath10k modules by > > sudo modprobe -r ath10k_pci > > then load ath10k modules with > > sudo modprobe ath10k_core debug_mask=0x > sudo modprobe ath10k_pci > > you should see lots of prints now BTW the extensive debug messages can slow down the system so there's also the option of using tracing which is a lot faster: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#tracing Though I have not tested that for a long time but I hope it still works. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Baochen Qiang writes: 2. invalid vht params rate 960 100kbps nss 1 mcs 9 3. invalid vht params rate 1730 100kbps nss 2 mcs 9 4. invalid vht params rate 1920 100kbps nss 2 mcs 9 >>> >>> OK, these are due to mismatch between host and QCA6174 firmware, we >>> can update host to fix them. > > Kalle, the root cause to these three warnings are clear now and if you > agree I can submit patches to fix them. Or I can also wait until the > NSS 3 issue is clear. I'm not sure why would we want to wait for the NSS 3 to be solved? Based on my (limited) understanding I think it would be good to submit patches for solved issues now. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: ath-next-20240702
Jeff Johnson writes: > On 7/3/2024 12:14 AM, Kalle Valo wrote: >> Kalle Valo writes: >>> I see a weird warning from gpg which I have never seen before: >>> >>> merged tag 'ath-next-20240702' >>> gpg: Signature made Tue 02 Jul 2024 05:55:42 PM EEST >>> gpg:using EDDSA key 3F9AD487CCF522D7A21F0C492C15BBA0898CCB7B >>> gpg:issuer "jjohn...@kernel.org" >>> gpg: Good signature from "Jeff Johnson " [full] >>> gpg: WARNING: We do NOT trust this key! >>> gpg: The signature is probably a FORGERY. >>> >>> It first says that the signature is good and then claims it's a forgery, >>> odd. Is this a problem between using different email addresses or what? >> >> I did 'gpg --refresh-keys', now your key contains your kernel.org >> address and I don't see the warning anymore. >> > > There had to be at least one issue with my first PR. Glad you sorted it out. > Key management is still a mystery to me... This wasn't a problem in your pull request, It was just a problem between my chair and my display ;) But I have to say that I hate PGP, "user friendly" is clearly not part of their vocabulary. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: ath-next-20240702
Jeff Johnson wrote: > The following changes since commit bb678f01804ccaa861b012b2b9426d69673d8a84: > > Merge branch 'intel-wired-lan-driver-updates-2024-06-03' (2024-06-10 > 19:52:50 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git > tags/ath-next-20240702 > > for you to fetch changes up to 5344fc76f8944249026884157f846f88489edfc0: > > wifi: ath12k: Support TQM stats (2024-07-01 21:57:28 +0300) > > > ath.git patches for v6.11 > > We have moved to a new group-managed repo, and this is the first pull > request from that repo, and from me. Fingers crossed... > > We have some new features in ath12k along with some cleanups in ath11k > and ath12k. Also notable are some device-tree changes to allow certain > ath11k and ath12k devices to work with a new power sequencing > subsystem. > > Major changes: > > ath12k > > * DebugFS support for datapath statistics > * WCN7850: support for WoW (Wake on WLAN) > * WCN7850: device-tree bindings > > ath11k > > * QCA6390: device-tree bindings > > > Aaradhana Sahu (3): > wifi: ath12k: Fix WARN_ON during firmware crash in split-phy > wifi: ath12k: fix NULL pointer access in ath12k_mac_op_get_survey() > wifi: ath12k: fix uninitialize symbol error on ath12k_peer_assoc_h_he() > > Aditya Kumar Singh (3): > wifi: ath12k: fix per pdev debugfs registration > wifi: ath12k: unregister per pdev debugfs > wifi: ath12k: handle symlink cleanup for per pdev debugfs dentry > > Ajith C (1): > wifi: ath12k: fix firmware crash due to invalid peer nss > > Baochen Qiang (11): > wifi: ath12k: fix ACPI warning when resume > wifi: ath11k: fix RCU documentation in ath11k_mac_op_ipv6_changed() > wifi: ath11k: fix wrong handling of CCMP256 and GCMP ciphers > wifi: ath12k: add ATH12K_DBG_WOW log level > wifi: ath12k: implement WoW enable and wakeup commands > wifi: ath12k: add basic WoW functionalities > wifi: ath12k: add WoW net-detect functionality > wifi: ath12k: implement hardware data filter > wifi: ath12k: support ARP and NS offload > wifi: ath12k: support GTK rekey offload > wifi: ath12k: handle keepalive during WoWLAN suspend and resume > > Bartosz Golaszewski (2): > dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390 > dt-bindings: net: wireless: describe the ath12k PCI module > > Dinesh Karthikeyan (6): > wifi: ath12k: Add support to enable debugfs_htt_stats > wifi: ath12k: Add htt_stats_dump file ops support > wifi: ath12k: Add support to parse requested stats_type > wifi: ath12k: Support Transmit Scheduler stats > wifi: ath12k: Support pdev error stats > wifi: ath12k: Support TQM stats > > Harshitha Prem (1): > wifi: ath12k: Remove unused ath12k_base from ath12k_hw > > Karthikeyan Periyasamy (3): > wifi: ath12k: avoid unnecessary MSDU drop in the Rx error process > wifi: ath12k: fix mbssid max interface advertisement > wifi: ath12k: fix peer metadata parsing > > Lingbo Kong (3): > wifi: ath11k: fix ack signal strength calculation > wifi: ath11k: modify the calculation of the average signal strength in > station mode > wifi: ath12k: Fix pdev id sent to firmware for single phy devices > > Pradeep Kumar Chitrapu (1): > wifi: ath12k: fix legacy peer association due to missing HT or 6 GHz > capabilities > > Rameshkumar Sundaram (2): > wifi: ath12k: modify remain on channel for single wiphy > wifi: ath12k: fix driver initialization for WoW unsupported devices > > Ramya Gnanasekar (1): > wifi: ath12k: Dump additional Tx PDEV HTT stats > > Wolfram Sang (1): > wifi: ath11k: use 'time_left' variable with wait_event_timeout() > > .../bindings/net/wireless/qcom,ath11k-pci.yaml | 46 + > .../bindings/net/wireless/qcom,ath12k.yaml | 99 ++ > drivers/net/wireless/ath/ath11k/dp_rx.c|3 +- > drivers/net/wireless/ath/ath11k/dp_rx.h|3 + > drivers/net/wireless/ath/ath11k/dp_tx.c| 16 +- > drivers/net/wireless/ath/ath11k/dp_tx.h|4 +- > drivers/net/wireless/ath/ath11k/hal_tx.h |4 +- > drivers/net/wireless/ath/ath11k/mac.c | 29 +- > drivers/net/wireless/ath/ath11k/qmi.c | 20 +- > drivers/net/wireless/ath/ath12k/Makefile |3 +- > drivers/net/wireless/ath/ath12k/acpi.c |2 + > drivers/net/wireless/ath/ath12k/core.c | 71 +- > drivers/net/wireless/ath/ath12k/core.h | 34 +- > drivers/net/wireless/ath/ath12k/debug.h|3 +- > drivers/net/wireless/ath/ath12k/debugfs.c | 19 +- > drivers/net/wireless/ath/ath12k/debugfs.h |6 +- >
Re: pull-request: ath-next-20240702
Kalle Valo writes: > Jeff Johnson writes: > >> The following changes since commit bb678f01804ccaa861b012b2b9426d69673d8a84: >> >> Merge branch 'intel-wired-lan-driver-updates-2024-06-03' >> (2024-06-10 19:52:50 -0700) >> >> are available in the Git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git >> tags/ath-next-20240702 >> >> for you to fetch changes up to 5344fc76f8944249026884157f846f88489edfc0: >> >> wifi: ath12k: Support TQM stats (2024-07-01 21:57:28 +0300) >> >> >> ath.git patches for v6.11 >> >> We have moved to a new group-managed repo, and this is the first pull >> request from that repo, and from me. Fingers crossed... >> >> We have some new features in ath12k along with some cleanups in ath11k >> and ath12k. Also notable are some device-tree changes to allow certain >> ath11k and ath12k devices to work with a new power sequencing >> subsystem. >> >> Major changes: >> >> ath12k >> >> * DebugFS support for datapath statistics >> * WCN7850: support for WoW (Wake on WLAN) >> * WCN7850: device-tree bindings >> >> ath11k >> >> * QCA6390: device-tree bindings >> >> > > I see a weird warning from gpg which I have never seen before: > > merged tag 'ath-next-20240702' > gpg: Signature made Tue 02 Jul 2024 05:55:42 PM EEST > gpg:using EDDSA key 3F9AD487CCF522D7A21F0C492C15BBA0898CCB7B > gpg:issuer "jjohn...@kernel.org" > gpg: Good signature from "Jeff Johnson " [full] > gpg: WARNING: We do NOT trust this key! > gpg: The signature is probably a FORGERY. > > It first says that the signature is good and then claims it's a forgery, > odd. Is this a problem between using different email addresses or what? I did 'gpg --refresh-keys', now your key contains your kernel.org address and I don't see the warning anymore. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: ath-next-20240702
Jeff Johnson writes: > The following changes since commit bb678f01804ccaa861b012b2b9426d69673d8a84: > > Merge branch 'intel-wired-lan-driver-updates-2024-06-03' (2024-06-10 > 19:52:50 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git > tags/ath-next-20240702 > > for you to fetch changes up to 5344fc76f8944249026884157f846f88489edfc0: > > wifi: ath12k: Support TQM stats (2024-07-01 21:57:28 +0300) > > > ath.git patches for v6.11 > > We have moved to a new group-managed repo, and this is the first pull > request from that repo, and from me. Fingers crossed... > > We have some new features in ath12k along with some cleanups in ath11k > and ath12k. Also notable are some device-tree changes to allow certain > ath11k and ath12k devices to work with a new power sequencing > subsystem. > > Major changes: > > ath12k > > * DebugFS support for datapath statistics > * WCN7850: support for WoW (Wake on WLAN) > * WCN7850: device-tree bindings > > ath11k > > * QCA6390: device-tree bindings > > I see a weird warning from gpg which I have never seen before: merged tag 'ath-next-20240702' gpg: Signature made Tue 02 Jul 2024 05:55:42 PM EEST gpg:using EDDSA key 3F9AD487CCF522D7A21F0C492C15BBA0898CCB7B gpg:issuer "jjohn...@kernel.org" gpg: Good signature from "Jeff Johnson " [full] gpg: WARNING: We do NOT trust this key! gpg: The signature is probably a FORGERY. It first says that the signature is good and then claims it's a forgery, odd. Is this a problem between using different email addresses or what? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
James Prestwood writes:
> HI Baochen,
>
> On 6/26/24 1:53 AM, Baochen Qiang wrote:
>>
>> On 6/18/2024 6:33 PM, Kalle Valo wrote:
>>> + baochen
>>>
>>> James Prestwood writes:
>>>
>>>> Hi Kalle,
>>>>
>>>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>>>> James Prestwood writes:
>>>>>
>>>>>> Hi Paul,
>>>>>>
>>>>>> On 6/16/24 6:10 AM, Paul Menzel wrote:
>>>>>>> Dear Linux folks,
>>>>>>>
>>>>>>>
>>>>>>> Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when
>>>>>>> connecting to a public WiFi:
>>>>>>>
>>>>>>> ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps
>>>>>>> nss 2 mcs 9
>>>>>> This has been reported/discussed [1]. It was hinted that there was a
>>>>>> firmware fix for this, but none that I tried got rid of it. I got fed
>>>>>> up enough with the logs filling up with this I patched our kernel to
>>>>>> remove the warning. AFAICT it appears benign (?). Removing the warning
>>>>>> was purely "cosmetic" so other devs stopped complaining about it :)
>>>>>>
>>>>>> [1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html
>>>>> More reliable link to the discussion:
>>>>>
>>>>> https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.sk...@linuxfoundation.org/
>>>>>
>>>>> I think we should add this workaround I mentioned in 2021:
>>>>>
>>>>> "If the firmware still keeps sending invalid rates we should add a
>>>>> specific check to ignore the known invalid values, but not all of
>>>>> them."
>>>>>
>>>>> https://lore.kernel.org/ath10k/87h7mktjgi@codeaurora.org/
>>>>>
>>>>> I guess that would be mcs == 7 and rate == 1440?
>>>> I think its more than this combination (Paul's are different).
>>> Good point.
>>>
>>>> So how many combinations are we willing to add here? Seems like that
>>>> could get out of hand if there are more than a few invalid
>>>> combinations.
>>> Yeah, but there haven't been that many different values reported yet,
>>> right? And I expect that ath10k user base will just get smaller in the
>>> future so the chances are that we will get less reports.
>>>
>>>> Would we also want to restrict the workaround to specific
>>>> hardware/firmware?
>>> Good idea, limiting per hardware would be simple to implement using
>>> hw_params. Of course we could even limit this per firmware version using
>>> enum ath10k_fw_features, but not sure if that's worth all the extra work.
>>>
>>> Baochen, do you know more about this firmware bug? Any suggestions?
>>
>> OK, there are two issues here:
>>
>> 1. invalid HT rate: "ath10k_pci :02:00.0: invalid ht params rate
>> 1440 100kbps nss 2 mcs 7".
>>
>> As commented by Wen quite some time ago, this has been fixed from
>> firmware side, and firmware newer than [ver:241] has the fix
>> included.
>
> Thanks for pointing this out, I guess I didn't look close enough at
> the log and missed "ht" vs "vht" when I brought it up on that older
> thread. I thought i was seeing the same problem even with newer
> firmware.
>>
>> 2. invaid VHT rate: "ath10k_pci :3a:00.0: invalid vht params
>> rate 1920 100kbps nss 2 mcs 9".
>>
>> After checking with firmware team, I thought this is because there
>> is a mismatch in rate definition between host and firmware: In host,
>> the rate for 'nss 2 mcs 9' is defined as {1560, 1733}, see
>> supported_vht_mcs_rate_nss2[]. While in firmware this is defined as
>> {1730, 1920}. So seems we can update host definition to avoid this
>> issue.
>
> That would be great!
Indeed! Baochen, can you work on a patch for ath10k to fix this?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH wireless] MAINTAINERS: wifi: update ath.git location
Kalle Valo wrote: > ath.git tree has moved to a new location. The old location will be an alias to > the new location and will work at least until end of 2024, but best to update > git trees already now. > > Signed-off-by: Kalle Valo > Acked-by: Jeff Johnson Patch applied to wireless.git, thanks. c40ff9b662d0 MAINTAINERS: wifi: update ath.git location -- https://patchwork.kernel.org/project/linux-wireless/patch/20240626102632.1554485-1-kv...@kernel.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Paul Menzel writes: >> All firmware releases are available here: >> https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware/-/tree/main/QCA6174/hw3.0/4.4.1?ref_type=heads >> And more info here: >> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware > > Thank you. It looks like the latest firmware version is 309, and > Debian sid/unstable still ships version 288 in *firmware-atheros* > 20230625-2 [1]. > > Unfortunately, there does not seem to be a change-log for version 309 > (or any version for that matter). I am going to manually copy it > anyway, but it’d be nice, if I knew what to expect. ;-) Yeah, unfortunately there are no changelogs available for firmware releases but I do understand the need for those. There has been discussions to create them but no success yet. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH wireless] MAINTAINERS: wifi: update ath.git location
ath.git tree has moved to a new location. The old location will be an alias to the new location and will work at least until end of 2024, but best to update git trees already now. Signed-off-by: Kalle Valo --- MAINTAINERS | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d6c90161c7bf..969412b75c46 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18376,7 +18376,7 @@ M: Jeff Johnson L: ath...@lists.infradead.org S: Supported W: https://wireless.wiki.kernel.org/en/users/Drivers/ath12k -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git F: drivers/net/wireless/ath/ath12k/ N: ath12k @@ -18386,7 +18386,7 @@ M: Jeff Johnson L: ath10k@lists.infradead.org S: Supported W: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git F: drivers/net/wireless/ath/ath10k/ N: ath10k @@ -18397,7 +18397,7 @@ L: ath...@lists.infradead.org S: Supported W: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k B: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k/bugreport -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git F: drivers/net/wireless/ath/ath11k/ N: ath11k @@ -18406,7 +18406,7 @@ M: Toke Høiland-Jørgensen L: linux-wirel...@vger.kernel.org S: Maintained W: https://wireless.wiki.kernel.org/en/users/Drivers/ath9k -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git F: Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml F: drivers/net/wireless/ath/ath9k/ base-commit: 321028bc45f01edb9e57b0ae5c11c5c3600d00ca -- 2.39.2
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Paul Menzel writes:
> Am 26.06.24 um 10:53 schrieb Baochen Qiang:
>
>> OK, there are two issues here:
>> 1. invalid HT rate: "ath10k_pci :02:00.0: invalid ht params rate
>> 1440 100kbps nss 2 mcs 7".
>> As commented by Wen quite some time ago, this has been fixed from
>> firmware side, and firmware newer than [ver:241] has the fix
>> included.
I assume this means that the firmware version
WLAN.RM.4.4.1-00241-QCARMSWPZ-1 or newer has the fix.
>> 2. invaid VHT rate: "ath10k_pci :3a:00.0: invalid vht params
>> rate 1920 100kbps nss 2 mcs 9".
>> After checking with firmware team, I thought this is because there
>> is
>> a mismatch in rate definition between host and firmware: In host, the
>> rate for 'nss 2 mcs 9' is defined as {1560, 1733}, see
>> supported_vht_mcs_rate_nss2[]. While in firmware this is defined as
>> {1730, 1920}. So seems we can update host definition to avoid this
>> issue.
> Looking through the logs since May 2024, I have four different logs:
>
> 1. invalid vht params rate 878 100kbps nss 3 mcs 2
> 2. invalid vht params rate 960 100kbps nss 1 mcs 9
> 3. invalid vht params rate 1730 100kbps nss 2 mcs 9
> 4. invalid vht params rate 1920 100kbps nss 2 mcs 9
>
> I believe it’s only happening with Cisco networks. I am happy to test
> a patch.
>
> By the way, is the firmware version logged by Linux?
>
> ath10k_pci :3a:00.0: qca6174 hw3.2 target 0x0503 chip_id
> 0x00340aff sub 1a56:1535
> ath10k_pci :3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0
> testmode 0
> ath10k_pci :3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6
> features wowlan,ignore-otp,mfp crc32 bf907c7c
> ath10k_pci :3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
> ath10k_pci :3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp
> max-sta 32 raw 0 hwcrypto 1
>
> Is it 4.4.1-00288?
Yes, that should be WLAN.RM.4.4.1-00288-QCARMSWPZ-1. But I don't know
why 'QCARMSWPZ-1' is not printed by ath10k, maybe we have a bug
somewhere.
> How can I find the file in `/lib/firmware/`?
It should be in ath10k/QCA6174/hw3.0/firmware-6.bin.
All firmware releases are available here:
https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware/-/tree/main/QCA6174/hw3.0/4.4.1?ref_type=heads
And more info here:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ieee80211.h virtual_map splat
Jakub Kicinski writes:
> On Tue, 25 Jun 2024 09:56:35 +0300 Kalle Valo wrote:
>> > Adding netdev to the initial message in the thread.
>> > https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=yts6e3...@mail.gmail.com/
>> >
>> > There was some discussion in the thread, with the observation that the
>> > splat
>> > is fixed by:
>> > 2ae5c9248e06 ("wifi: mac80211: Use flexible array in struct
>> > ieee80211_tim_ie")
>> >
>> > Followed by discussion if this should be backported.
>> >
>> > Kees said that "netdev [...] maintainers have asked that contributors not
>> > include "Cc: stable" tags, as they want to evaluate for themselves whether
>> > patches should go to stable or not"
>>
>> BTW this rule doesn't apply to wireless subsystem. For wireless patches
>> it's ok to "Cc: stable" in patches or anyone can send a request to
>> stable maintainers to pick a patch.
>
> It's an old rule. Quoting documentation:
>
> Stable tree
> ~~~
>
> While it used to be the case that netdev submissions were not supposed
> to carry explicit ``CC: sta...@vger.kernel.org`` tags that is no longer
> the case today. Please follow the standard stable rules in
> :ref:`Documentation/process/stable-kernel-rules.rst `,
> and make sure you include appropriate Fixes tags!
>
> See:
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#stable-tree
Oh, I haven't noticed the change. Thanks for correcting.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ieee80211.h virtual_map splat
Jeff Johnson writes:
> On 6/21/2024 1:04 AM, Koen Vandeputte wrote:
>
>> Hi all,
>>
>> Within OpenWRT, we switched to kernel 6.6 some time ago.
>>
>> During testing on a WiFi WDS setup (ath10k), I noticed an old standing
>> bug which now prints a lot more data due to the kernel upgrade:
>>
>> - All WDS stations are connected
>> - The splat occurs
>> - All WDS station seem to go in timeout and disconnect
>> - The behavior is fixed after a reboot
>>
>> Yes, we use ath10k-ct over here, but this part of the code is
>> identical to upstream ath10k.
>>
>> The main issue:
>>
>> memcpy: detected field-spanning write (size 64) of single field
>> "tim->virtual_map" at
>> ../ath10k-ct-smallbuffers/ath10k-ct-2024.03.02~eb3f488a/ath10k-6.7/wmi.c:4043
>> (size 1)
>>
>>
>> looks like virtual_map is defined as "u8 virtual_map[1]", triggering
>> that error within "include/linux/ieee80211.h"
>>
>> /**
>> * struct ieee80211_tim_ie - Traffic Indication Map information element
>> * @dtim_count: DTIM Count
>> * @dtim_period: DTIM Period
>> * @bitmap_ctrl: Bitmap Control
>> * @virtual_map: Partial Virtual Bitmap
>> *
>> * This structure represents the payload of the "TIM element" as
>> * described in IEEE Std 802.11-2020 section 9.4.2.5.
>> */
>> struct ieee80211_tim_ie {
>> u8 dtim_count;
>> u8 dtim_period;
>> u8 bitmap_ctrl;
>> /* variable size: 1 - 251 bytes */
>> u8 virtual_map[1];
>> } __packed;
>>
>>
>> According to this page, defining it this way is actually deprecated:
>> https://www.kernel.org/doc/html/latest/process/deprecated.html
>>
>> What is the correct way to fix this?
>> Converting it to "u8 virtual_map[];" ?
>
> Adding netdev to the initial message in the thread.
> https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=yts6e3...@mail.gmail.com/
>
> There was some discussion in the thread, with the observation that the splat
> is fixed by:
> 2ae5c9248e06 ("wifi: mac80211: Use flexible array in struct ieee80211_tim_ie")
>
> Followed by discussion if this should be backported.
>
> Kees said that "netdev [...] maintainers have asked that contributors not
> include "Cc: stable" tags, as they want to evaluate for themselves whether
> patches should go to stable or not"
BTW this rule doesn't apply to wireless subsystem. For wireless patches
it's ok to "Cc: stable" in patches or anyone can send a request to
stable maintainers to pick a patch.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
+ baochen James Prestwood writes: > Hi Kalle, > > On 6/17/24 8:27 AM, Kalle Valo wrote: >> James Prestwood writes: >> >>> Hi Paul, >>> >>> On 6/16/24 6:10 AM, Paul Menzel wrote: >>>> Dear Linux folks, >>>> >>>> >>>> Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when >>>> connecting to a public WiFi: >>>> >>>> ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps >>>> nss 2 mcs 9 >>> This has been reported/discussed [1]. It was hinted that there was a >>> firmware fix for this, but none that I tried got rid of it. I got fed >>> up enough with the logs filling up with this I patched our kernel to >>> remove the warning. AFAICT it appears benign (?). Removing the warning >>> was purely "cosmetic" so other devs stopped complaining about it :) >>> >>> [1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html >> More reliable link to the discussion: >> >> https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.sk...@linuxfoundation.org/ >> >> I think we should add this workaround I mentioned in 2021: >> >> "If the firmware still keeps sending invalid rates we should add a >> specific check to ignore the known invalid values, but not all of >> them." >> >> https://lore.kernel.org/ath10k/87h7mktjgi@codeaurora.org/ >> >> I guess that would be mcs == 7 and rate == 1440? > > I think its more than this combination (Paul's are different). Good point. > So how many combinations are we willing to add here? Seems like that > could get out of hand if there are more than a few invalid > combinations. Yeah, but there haven't been that many different values reported yet, right? And I expect that ath10k user base will just get smaller in the future so the chances are that we will get less reports. > Would we also want to restrict the workaround to specific > hardware/firmware? Good idea, limiting per hardware would be simple to implement using hw_params. Of course we could even limit this per firmware version using enum ath10k_fw_features, but not sure if that's worth all the extra work. Baochen, do you know more about this firmware bug? Any suggestions? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
James Prestwood writes: > Hi Paul, > > On 6/16/24 6:10 AM, Paul Menzel wrote: >> Dear Linux folks, >> >> >> Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when >> connecting to a public WiFi: >> >> ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps >> nss 2 mcs 9 > > This has been reported/discussed [1]. It was hinted that there was a > firmware fix for this, but none that I tried got rid of it. I got fed > up enough with the logs filling up with this I patched our kernel to > remove the warning. AFAICT it appears benign (?). Removing the warning > was purely "cosmetic" so other devs stopped complaining about it :) > > [1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html More reliable link to the discussion: https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.sk...@linuxfoundation.org/ I think we should add this workaround I mentioned in 2021: "If the firmware still keeps sending invalid rates we should add a specific check to ignore the known invalid values, but not all of them." https://lore.kernel.org/ath10k/87h7mktjgi@codeaurora.org/ I guess that would be mcs == 7 and rate == 1440? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: ath-next-20240605
Kalle Valo wrote: > Hi, > > Please pull, more information in the tag below. > > Kalle > > The following changes since commit f1c26960b6afb9c38a4019ad36392c654db6e20e: > > Merge tag 'ath-next-20240502' of > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath (2024-05-03 13:30:19 > +0300) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git > tags/ath-next-20240605 > > for you to fetch changes up to 22767241e64427bbcffea2e2d51531ab467bc4ef: > > wifi: ath12k: add hw_link_id in ath12k_pdev (2024-06-03 16:15:50 +0300) > > > ath.git patches for v6.11 > > ath12k > > * remove unsupported tx monitor handling > > * channel 2 in 6 GHz band support > > * Spatial Multiplexing Power Save (SMPS) in 6 GHz band support > > * multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA) > support > > * dynamic VLAN support > > * add panic handler for resetting the firmware state > > ath10k > > * add qcom,no-msa-ready-indicator Device Tree property > > * LED support for various chipsets > > > Aloka Dixit (9): > wifi: ath12k: advertise driver capabilities for MBSSID and EMA > wifi: ath12k: configure MBSSID params in vdev create/start > wifi: ath12k: rename MBSSID fields in wmi_vdev_up_cmd > wifi: ath12k: create a structure for WMI vdev up parameters > wifi: ath12k: configure MBSSID parameters in AP mode > wifi: ath12k: refactor arvif security parameter configuration > wifi: ath12k: add MBSSID beacon support > wifi: ath12k: add EMA beacon support > wifi: ath12k: skip sending vdev down for channel switch > > Baochen Qiang (9): > wifi: ath12k: fix Smatch warnings on ath12k_core_suspend() > wifi: ath11k: refactor setting country code logic > wifi: ath11k: restore country code during resume > wifi: ath11k: fix wrong definition of CE ring's base address > wifi: ath12k: fix race due to setting ATH12K_FLAG_EXT_IRQ_ENABLED too > early > wifi: ath12k: fix wrong definition of CE ring's base address > wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup() > wifi: ath12k: do not process consecutive RDDM event > wifi: ath12k: add panic handler > > Breno Leitao (2): > wifi: wil6210: Do not use embedded netdev in wil6210_priv > wifi: ath12k: allocate dummy net_device dynamically > > Jeff Johnson (8): > wifi: ath11k: refactor CE remap & unmap > wifi: ath11k: unmap the CE in ath11k_ahb_probe() error path > wifi: ath12k: initialize 'ret' in ath12k_qmi_load_file_target_mem() > wifi: ath11k: initialize 'ret' in ath11k_qmi_load_file_target_mem() > wifi: ath11k: fix misspelling of "dma" in num_rxmda_per_pdev > wifi: ath12k: fix misspelling of "dma" in num_rxmda_per_pdev > wifi: ath12k: initialize 'ret' in > ath12k_dp_rxdma_ring_sel_config_wcn7850() > wifi: ath12k: Fix devmem address prefix when logging > > Kalle Valo (1): > wifi: ath11k: ath11k_mac_op_ipv6_changed(): use list_for_each_entry() > > Kang Yang (5): > wifi: ath12k: remove unused variable monitor_flags > wifi: ath12k: avoid duplicated vdev stop > wifi: ath12k: avoid duplicated vdev down > wifi: ath12k: remove invalid peer create logic > wifi: ath12k: remove redundant peer delete for WCN7850 > > Karthikeyan Kathirvel (1): > wifi: ath12k: drop failed transmitted frames from metric calculation. > > Karthikeyan Periyasamy (13): > wifi: ath12k: Refactor the hardware recovery procedure > wifi: ath12k: Refactor the hardware state > wifi: ath12k: Add lock to protect the hardware state > wifi: ath12k: Replace "chip" with "device" in hal Rx return buffer > manager > wifi: ath12k: Refactor idle ring descriptor setup > wifi: ath12k: Introduce device index > wifi: ath12k: add multi device support for WBM idle ring buffer setup > wifi: ath12k: avoid double SW2HW_MACID conversion > wifi: ath12k: remove duplicate definition of MAX_RADIOS > wifi: ath12k: use correct MAX_RADIOS > wifi: ath12k: refactor rx descriptor CMEM configuration > wifi: ath12k: improve the rx descriptor error information > wifi: ath12k: add hw_link_id in ath12k_pdev > > Lingbo Kong (1): > wifi: ath12k: fix ack signal strength calculation > > Marc Gonzalez (2):
pull-request: ath-next-20240605
Hi, Please pull, more information in the tag below. Kalle The following changes since commit f1c26960b6afb9c38a4019ad36392c654db6e20e: Merge tag 'ath-next-20240502' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath (2024-05-03 13:30:19 +0300) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git tags/ath-next-20240605 for you to fetch changes up to 22767241e64427bbcffea2e2d51531ab467bc4ef: wifi: ath12k: add hw_link_id in ath12k_pdev (2024-06-03 16:15:50 +0300) ath.git patches for v6.11 ath12k * remove unsupported tx monitor handling * channel 2 in 6 GHz band support * Spatial Multiplexing Power Save (SMPS) in 6 GHz band support * multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA) support * dynamic VLAN support * add panic handler for resetting the firmware state ath10k * add qcom,no-msa-ready-indicator Device Tree property * LED support for various chipsets Aloka Dixit (9): wifi: ath12k: advertise driver capabilities for MBSSID and EMA wifi: ath12k: configure MBSSID params in vdev create/start wifi: ath12k: rename MBSSID fields in wmi_vdev_up_cmd wifi: ath12k: create a structure for WMI vdev up parameters wifi: ath12k: configure MBSSID parameters in AP mode wifi: ath12k: refactor arvif security parameter configuration wifi: ath12k: add MBSSID beacon support wifi: ath12k: add EMA beacon support wifi: ath12k: skip sending vdev down for channel switch Baochen Qiang (9): wifi: ath12k: fix Smatch warnings on ath12k_core_suspend() wifi: ath11k: refactor setting country code logic wifi: ath11k: restore country code during resume wifi: ath11k: fix wrong definition of CE ring's base address wifi: ath12k: fix race due to setting ATH12K_FLAG_EXT_IRQ_ENABLED too early wifi: ath12k: fix wrong definition of CE ring's base address wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup() wifi: ath12k: do not process consecutive RDDM event wifi: ath12k: add panic handler Breno Leitao (2): wifi: wil6210: Do not use embedded netdev in wil6210_priv wifi: ath12k: allocate dummy net_device dynamically Jeff Johnson (8): wifi: ath11k: refactor CE remap & unmap wifi: ath11k: unmap the CE in ath11k_ahb_probe() error path wifi: ath12k: initialize 'ret' in ath12k_qmi_load_file_target_mem() wifi: ath11k: initialize 'ret' in ath11k_qmi_load_file_target_mem() wifi: ath11k: fix misspelling of "dma" in num_rxmda_per_pdev wifi: ath12k: fix misspelling of "dma" in num_rxmda_per_pdev wifi: ath12k: initialize 'ret' in ath12k_dp_rxdma_ring_sel_config_wcn7850() wifi: ath12k: Fix devmem address prefix when logging Kalle Valo (1): wifi: ath11k: ath11k_mac_op_ipv6_changed(): use list_for_each_entry() Kang Yang (5): wifi: ath12k: remove unused variable monitor_flags wifi: ath12k: avoid duplicated vdev stop wifi: ath12k: avoid duplicated vdev down wifi: ath12k: remove invalid peer create logic wifi: ath12k: remove redundant peer delete for WCN7850 Karthikeyan Kathirvel (1): wifi: ath12k: drop failed transmitted frames from metric calculation. Karthikeyan Periyasamy (13): wifi: ath12k: Refactor the hardware recovery procedure wifi: ath12k: Refactor the hardware state wifi: ath12k: Add lock to protect the hardware state wifi: ath12k: Replace "chip" with "device" in hal Rx return buffer manager wifi: ath12k: Refactor idle ring descriptor setup wifi: ath12k: Introduce device index wifi: ath12k: add multi device support for WBM idle ring buffer setup wifi: ath12k: avoid double SW2HW_MACID conversion wifi: ath12k: remove duplicate definition of MAX_RADIOS wifi: ath12k: use correct MAX_RADIOS wifi: ath12k: refactor rx descriptor CMEM configuration wifi: ath12k: improve the rx descriptor error information wifi: ath12k: add hw_link_id in ath12k_pdev Lingbo Kong (1): wifi: ath12k: fix ack signal strength calculation Marc Gonzalez (2): dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop wifi: ath10k: do not always wait for MSA_READY indicator Muna Sinada (1): wifi: ath12k: dynamic VLAN support Nithyanantham Paramasivam (1): wifi: ath12k: Fix tx completion ring (WBM2SW) setup failure P Praneesh (3): wifi: ath12k: change DMA direction while mapping reinjected packets wifi: ath12k: fix invalid memory access while processing fragmented packets wifi: ath12k: fix firmware crash during reo reinject Pradeep Kumar Chitrapu (6): wifi: ath12k: add channel 2 into 6 GHz
Re: New staging repos for ath1*k firmware
Kalle Valo writes: > Jeff Johnson writes: > >> Historically, prior to being incorporated into the linux-firmware >> project, firmware for kernel.org ath1*k drivers has been first published >> to Kalle's GitHub: >> https://github.com/kvalo/ath10k-firmware >> https://github.com/kvalo/ath11k-firmware >> (ath12k firmware was pushed to the ath11k-firmware repo on a temporary >> basis in anticipation of this move) >> >> But in order to have repos with multiple maintainers, as well as to have >> a hosting platform with more control, we have moved to CodeLinaro: >> https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware >> https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware >> https://git.codelinaro.org/clo/ath-firmware/ath12k-firmware >> >> Note that most people should not care about this -- normally you should >> use the firmware that is in the official linux-firmware repo: >> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ >> >> You should only need to access the staging repos if you need a previous >> version to work around an issue, or if you are testing new firmware that >> is supposed to fix a problem that you've reported. >> >> Please let Kalle & I know if you have any issues with these new repos! > > The final reminder that the github.com repositories will be deleted in > two weeks. If someone is still using them switch to the new > git.codelinaro.org location NOW. And github.com repos are gone now. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: ath-current-20240531
Kalle Valo wrote: > Hi, > > Please pull, more information in the tag below. > > Kalle > > The following changes since commit 1d60eabb82694e58543e2b6366dae3e7465892a5: > > wifi: mwl8k: initialize cmd->addr[] properly (2024-05-07 15:08:14 +0300) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git > tags/ath-current-20240531 > > for you to fetch changes up to 6e16782d6b4a724f9c9dcd49471219643593b60c: > > wifi: ath11k: move power type check to ASSOC stage when connecting to 6 GHz > AP (2024-05-23 15:45:52 +0300) > > > Merge ath-current from > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git > > ath.git fixes for 6.10. Two fixes for user reported regressions in > ath11k. One dependency fix and one error path fix. > > > Baochen Qiang (1): > wifi: ath11k: move power type check to ASSOC stage when connecting to 6 > GHz AP > > Breno Leitao (1): > wifi: ath11k: Fix error path in ath11k_pcic_ext_irq_config > > Carl Huang (1): > wifi: ath11k: fix WCN6750 firmware crash caused by 17 num_vdevs > > Dmitry Baryshkov (1): > wifi: ath10k: fix QCOM_RPROC_COMMON dependency > > drivers/net/wireless/ath/ath10k/Kconfig | 1 + > drivers/net/wireless/ath/ath11k/core.c | 2 +- > drivers/net/wireless/ath/ath11k/mac.c | 38 > ++--- > drivers/net/wireless/ath/ath11k/pcic.c | 25 +++--- > 4 files changed, 44 insertions(+), 22 deletions(-) Pulled, thanks. 10bc8558b59a Merge tag 'ath-current-20240531' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath -- https://patchwork.kernel.org/project/linux-wireless/patch/87ttidvrup@kernel.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
pull-request: ath-current-20240531
Hi, Please pull, more information in the tag below. Kalle The following changes since commit 1d60eabb82694e58543e2b6366dae3e7465892a5: wifi: mwl8k: initialize cmd->addr[] properly (2024-05-07 15:08:14 +0300) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git tags/ath-current-20240531 for you to fetch changes up to 6e16782d6b4a724f9c9dcd49471219643593b60c: wifi: ath11k: move power type check to ASSOC stage when connecting to 6 GHz AP (2024-05-23 15:45:52 +0300) Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath.git fixes for 6.10. Two fixes for user reported regressions in ath11k. One dependency fix and one error path fix. Baochen Qiang (1): wifi: ath11k: move power type check to ASSOC stage when connecting to 6 GHz AP Breno Leitao (1): wifi: ath11k: Fix error path in ath11k_pcic_ext_irq_config Carl Huang (1): wifi: ath11k: fix WCN6750 firmware crash caused by 17 num_vdevs Dmitry Baryshkov (1): wifi: ath10k: fix QCOM_RPROC_COMMON dependency drivers/net/wireless/ath/ath10k/Kconfig | 1 + drivers/net/wireless/ath/ath11k/core.c | 2 +- drivers/net/wireless/ath/ath11k/mac.c | 38 ++--- drivers/net/wireless/ath/ath11k/pcic.c | 25 +++--- 4 files changed, 44 insertions(+), 22 deletions(-)
Re: [PATCH v3 1/3] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Marc Gonzalez writes: > On 28/05/2024 12:11, Kalle Valo wrote: > >> Marc Gonzalez writes: >> >>> On 13/05/2024 16:16, Kalle Valo wrote: >>> >>>> 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: Marc Gonzalez >>>>> Reviewed-by: Bjorn Andersson >>>>> Acked-by: Jeff Johnson >>>>> Acked-by: Rob Herring (Arm) >>>>> Signed-off-by: Kalle Valo >>>> >>>> 2 patches applied to ath-next branch of ath.git, thanks. >>>> >>>> 71b6e321e302 dt-bindings: net: wireless: ath10k: add >>>> qcom,no-msa-ready-indicator prop >>>> 6d67d18014a8 wifi: ath10k: do not always wait for MSA_READY indicator >>> >>> Hello Kalle, >>> What version of Linux will these be included in? >>> (I don't see them in v6.10-rc1. Are they considered >>> a new feature, rather than a fix, and thus 6.11?) >> >> Yeah, these commits will go to v6.11. Because of the multiple trees >> involved (ath-next -> wireless-next -> net-next -> linus) we need to >> have ath.git pull request ready well before the merge window opens and >> these commits missed the last pull request. >> >> Yes, we are slow :) > > My understanding of the merging process was that > > - new features are queued for the next cycle, > so vN+1-rc1, or vN+2-rc1 if the submission came too late (after ~rc6) in > cycle N > > - fixes are queued for the fixes batch in the same cycle > > This patch series is handled like a feature rather than a fix? > (To me, it fixed broken behavior in the FW, but I understand > if the nature of the changes require a more prudent approach. > Though they are disabled for everyone by default.) So the path for ath10k/ath11k/ath12k fixes to current -rc release is: ath-current -> wireless -> net -> linus For new features going to the next release: ath-next -> wireless-next -> net-next -> (in merge window) linus To reduce conflicts between trees most of the patches I apply go to -next, I usually take only important regression fixes to -current. In this case I didn't even consider taking the patches to -current as there were changes in DT and I just assumed this is for -next. If you considered otherwise I didn't realise it, sorry about that. In future, if you think a patch should go to -current please mention it somewhere, preferably something like tagging it with "[PATCH wireless]" or "[PATCH ath-current]" etc. to document which tree it is for. Or just as a simple reply. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v3 1/3] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Marc Gonzalez writes: > On 13/05/2024 16:16, Kalle Valo wrote: > >> 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: Marc Gonzalez >>> Reviewed-by: Bjorn Andersson >>> Acked-by: Jeff Johnson >>> Acked-by: Rob Herring (Arm) >>> Signed-off-by: Kalle Valo >> >> 2 patches applied to ath-next branch of ath.git, thanks. >> >> 71b6e321e302 dt-bindings: net: wireless: ath10k: add >> qcom,no-msa-ready-indicator prop >> 6d67d18014a8 wifi: ath10k: do not always wait for MSA_READY indicator > > Hello Kalle, > What version of Linux will these be included in? > (I don't see them in v6.10-rc1. Are they considered > a new feature, rather than a fix, and thus 6.11?) Yeah, these commits will go to v6.11. Because of the multiple trees involved (ath-next -> wireless-next -> net-next -> linus) we need to have ath.git pull request ready well before the merge window opens and these commits missed the last pull request. Yes, we are slow :) -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath10k_pci 0000:3a:00.0: Could not init core: -110
Paul Menzel writes: > Dear Kalle, dear Baochen, > > > Am 27.05.24 um 11:10 schrieb Kalle Valo: >> Baochen Qiang writes: >> >>> On 5/27/2024 4:42 PM, Paul Menzel wrote: > >>>> On the Intel Kaby Lake notebook Dell XPS 13 with >>>> >>>> 3a:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 >>>> 802.11ac Wireless Network Adapter [168c:003e] (rev 32) >>>> >>>> with at least a self-built Linux 6.9-rc5, on April 26th, 2024, and >>>> Linux 6.8.11, today, May 27th, 2024, the error below happened, and >>>> the device couldn’t authenticate to a WiFi network until reloading >>>> the module *ath10k_core* and *ath10k_pci* (didn’t check just >>>> *ath10k_pci*): >>>> >>>> $ sudo modprobe -r ath10k_pci >>>> $ sudo modprobe -r ath10k_core >>>> $ sudo modprobe ath10k_pci >>>> >>>> ``` >>>> [ 49.441618] ath10k_pci :3a:00.0: wmi service ready event not >>>> received >>>> [ 49.523814] ath10k_pci :3a:00.0: Could not init core: -110 >> [...] >> >>> Are you using a distro kernel? > > The 6.8.11 is Debian’s current Linux kernel in the suite *unstable/sid* > (*linux-image-6.8.11-amd64* 6.8.11-1). > >>> Could you check if below patch merged in your kernel? if not can >>> you merge it and try again? >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=e57b7d62a1b2f496caf0beba81cec3c90fad80d5 >> Paul, if you are feeling brave to try out an -rc this commit is in >> just >> released v6.10-rc1. > > Thank you. I haven’t found out yet, how to reproduce this. I’ll keep > an eye on it. > > As the commit message says: > >> This results in timeout issue if the interrupt is not fired, due to >> some unknown reasons. > > There are reports from 2016 to 2021 with similar symptoms. These were > supposedly fixed with > `/usr/lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin` [1][2]: > > $ md5sum /usr/lib/firmware/ath10k/QCA6174/hw3.0/board.bin > /usr/lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin > cb37c63d9ca28f53fea1ff09ad7c7a82 > /usr/lib/firmware/ath10k/QCA6174/hw3.0/board.bin > 651e921b372848b3928621e6f1d34b01 > /usr/lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin Most likely that's a different issue from yours, just with same symptoms (firmware crashing during firmware initialisation). I have seen also cases when the firmware crashes when using a wrong board file, but I suspect your board file is correct. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath10k_pci 0000:3a:00.0: Could not init core: -110
Baochen Qiang writes: > On 5/27/2024 4:42 PM, Paul Menzel wrote: >> Dear Linux folks, >> >> >> On the Intel Kaby Lake notebook Dell XPS 13 with >> >> 3a:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 >> 802.11ac Wireless Network Adapter [168c:003e] (rev 32) >> >> with at least a self-built Linux 6.9-rc5, on April 26th, 2024, and >> Linux 6.8.11, today, May 27th, 2024, the error below happened, and >> the device couldn’t authenticate to a WiFi network until reloading >> the module *ath10k_core* and *ath10k_pci* (didn’t check just >> *ath10k_pci*): >> >> $ sudo modprobe -r ath10k_pci >> $ sudo modprobe -r ath10k_core >> $ sudo modprobe ath10k_pci >> >> ``` >> [ 49.441618] ath10k_pci :3a:00.0: wmi service ready event not received >> [ 49.523814] ath10k_pci :3a:00.0: Could not init core: -110 [...] > Are you using a distro kernel? Could you check if below patch merged > in your kernel? if not can you merge it and try again? > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=e57b7d62a1b2f496caf0beba81cec3c90fad80d5 Paul, if you are feeling brave to try out an -rc this commit is in just released v6.10-rc1. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] wifi: ath10k: fix QCOM_RPROC_COMMON dependency
Dmitry Baryshkov wrote:
> If ath10k_snoc is built-in, while Qualcomm remoteprocs are built as
> modules, compilation fails with:
>
> /usr/bin/aarch64-linux-gnu-ld: drivers/net/wireless/ath/ath10k/snoc.o: in
> function `ath10k_modem_init':
> drivers/net/wireless/ath/ath10k/snoc.c:1534: undefined reference to
> `qcom_register_ssr_notifier'
> /usr/bin/aarch64-linux-gnu-ld: drivers/net/wireless/ath/ath10k/snoc.o: in
> function `ath10k_modem_deinit':
> drivers/net/wireless/ath/ath10k/snoc.c:1551: undefined reference to
> `qcom_unregister_ssr_notifier'
>
> Add corresponding dependency to ATH10K_SNOC Kconfig entry so that it's
> built as module if QCOM_RPROC_COMMON is built as module too.
>
> Fixes: 747ff7d3d742 ("ath10k: Don't always treat modem stop events as
> crashes")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Baryshkov
> Signed-off-by: Kalle Valo
Patch applied to ath-current branch of ath.git, thanks.
21ae74e1bf18 wifi: ath10k: fix QCOM_RPROC_COMMON dependency
--
https://patchwork.kernel.org/project/linux-wireless/patch/20240511-ath10k-snoc-dep-v1-1-9666e3af5...@linaro.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
Eric Park writes: > On 5/15/24 5:04 PM, Kalle Valo wrote: > >> Eric Park writes: >>> I'm unsure what to test next, if it can be triaged at all. It's an >>> outdated card in a really old laptop and I can always work around it >>> with a USB WiFi adapter. If anyone has any suggestions I'm all ears >>> but otherwise I think this would be a good place to stop. >> One thing to try is to make sure your setup matches what James is using, >> especially the firmware version. > > Interesting, this is what I get from `dmesg`: > > qca6174 hw2.1 target 0x0501 chip_id 0x003405ff sub 144d:4125 > firmware ver SW_RM.1.1.1-00157-QCARMSWPZ-1 api 5 features ignore-otp, > no-4addr-pad crc32 10bf8e08 > > I'm guessing the firmware version 1.1.1 is the latest one for the hw > 2.1 variant (going off of the firmware repository), but please correct > me if I'm wrong! > > Looking at the repository that version was updated 8 years ago. Is > there anything else I can try? I'm guessing newer firmware only > works on the newer hardware revisions. Aha! I had totally missed that you are using hw2.1. (James is using hw3.2) Yeah, that hardware version has been problematic almost since the beginning and there has been any firmware updates for a long time. I'm not surprised at all that 802.11w is slow on hw2.1. I think disabling 802.11w for QCA6174 hw2.1 is a good idea, patches welcome. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: New staging repos for ath1*k firmware
Jeff Johnson writes: > Historically, prior to being incorporated into the linux-firmware > project, firmware for kernel.org ath1*k drivers has been first published > to Kalle's GitHub: > https://github.com/kvalo/ath10k-firmware > https://github.com/kvalo/ath11k-firmware > (ath12k firmware was pushed to the ath11k-firmware repo on a temporary > basis in anticipation of this move) > > But in order to have repos with multiple maintainers, as well as to have > a hosting platform with more control, we have moved to CodeLinaro: > https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware > https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware > https://git.codelinaro.org/clo/ath-firmware/ath12k-firmware > > Note that most people should not care about this -- normally you should > use the firmware that is in the official linux-firmware repo: > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ > > You should only need to access the staging repos if you need a previous > version to work around an issue, or if you are testing new firmware that > is supposed to fix a problem that you've reported. > > Please let Kalle & I know if you have any issues with these new repos! The final reminder that the github.com repositories will be deleted in two weeks. If someone is still using them switch to the new git.codelinaro.org location NOW. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v14] ath10k: add LED and GPIO controlling support for various chipsets
Christian Marangi wrote: > Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 > based chipsets with on chipset connected led's using WMI Firmware API. > The LED device will get available named as "ath10k-phyX" at sysfs and > can be controlled with various triggers. > Adds also debugfs interface for gpio control. > > Signed-off-by: Sebastian Gottschall > Reviewed-by: Steve deRosier > [kvalo: major reorg and cleanup] > Signed-off-by: Kalle Valo > [ansuel: rebase and small cleanup] > Signed-off-by: Christian Marangi > Tested-by: Stefan Lippers-Hollmann > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 8e1debd82466 wifi: ath10k: add LED and GPIO controlling support for various chipsets -- https://patchwork.kernel.org/project/linux-wireless/patch/20230611080505.17393-1-ansuels...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
Eric Park writes: > On 5/15/2024 12:27 AM, Kalle Valo wrote: > >> But James is reporting[1] that 802.11w is working for him. So it doesn't >> seem to be completely broken even if you are having problems and >> removing the 802.11w support from the driver doesn't sound right. >> >> [1] >> https://lore.kernel.org/all/ce0e2043-5085-4dd6-86bd-89dca6f56...@gmail.com/ > > I actually didn't see that email -- I'm not very familiar with how > mailing lists work but I guess I have to be subscribed to receive > updates, even for mail chains that I've started. So thank you for > linking me his email. Usually we cc people so that people don't need to subscribe to lists, but for some reason James didn't do that in this case. You can also follow ath10k list via lore: https://lore.kernel.org/ath10k/ And there's also lei which some people are using: https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started > I'm unsure what to test next, if it can be triaged at all. It's an > outdated card in a really old laptop and I can always work around it > with a USB WiFi adapter. If anyone has any suggestions I'm all ears > but otherwise I think this would be a good place to stop. One thing to try is to make sure your setup matches what James is using, especially the firmware version. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
Eric Park writes: > 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? But James is reporting[1] that 802.11w is working for him. So it doesn't seem to be completely broken even if you are having problems and removing the 802.11w support from the driver doesn't sound right. [1] https://lore.kernel.org/all/ce0e2043-5085-4dd6-86bd-89dca6f56...@gmail.com/ -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v3 1/3] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
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: Marc Gonzalez > Reviewed-by: Bjorn Andersson > Acked-by: Jeff Johnson > Acked-by: Rob Herring (Arm) > Signed-off-by: Kalle Valo 2 patches applied to ath-next branch of ath.git, thanks. 71b6e321e302 dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop 6d67d18014a8 wifi: ath10k: do not always wait for MSA_READY indicator -- https://patchwork.kernel.org/project/linux-wireless/patch/54ac2295-36b4-49fc-9583-a10db8d9d...@freebox.fr/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v14] ath10k: add LED and GPIO controlling support for various chipsets
Jeff Johnson writes: > On 5/10/2024 7:14 AM, Christian Marangi wrote: > >> On Thu, May 09, 2024 at 09:48:08AM -0700, Jeff Johnson wrote: >>> On 5/9/2024 9:37 AM, Jeff Johnson wrote: >>>> On 5/8/2024 9:50 PM, Kalle Valo wrote: >>>>> Sorry for the delay but finally I looked at this again. I decided to >>>>> just remove the fixme and otherwise it looks good for me. Please check >>>>> my changes: >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=688130a66ed49f20ca0ce02c3987f6a474f7c93a >>>>> >>>> >>>> I have a question about the copyrights in the two new files: >>>> + * Copyright (c) 2018-2023, The Linux Foundation. All rights reserved. >>>> >>>> My understanding is that Qualcomm's affiliation with Linux Foundation via >>>> Code >>>> Aurora ended in December 2021, and hence any contributions in 2022-2023 >>>> should >>>> be the copyright of Qualcomm Innovation Center, Inc. >>>> >>>> >>> >>> ok it seems like Kalle's v13 had: >>> + * Copyright (c) 2018, The Linux Foundation. All rights reserved. >>> >>> and Ansuel's v14 has: >>> + * Copyright (c) 2018-2023, The Linux Foundation. All rights reserved. >>> >>> So Ansuel, is your work on behalf of The Linux Foundation? >>> >> >> When I resubmitted this at times, I just updated the copyright to the >> current year so I guess it was wrong doing that? >> >> As you can see from the copyright header this patch went all around and >> I think at the end (around 2018) the Linux copyright was added as it was >> submitted upstream. (can't remember if maintainers were asking that) >> >> So me watching the old year and resubmitting it, just updated the date. >> >> Soo I think we should revert to 2018? >> > > Yes, in this case changing the Linux Foundation copyright back to 2018 is > correct. I changed it now back to 2018, please check: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=5eff06bef76b6d4e1553c2d4978025c329d8db35 -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v14] ath10k: add LED and GPIO controlling support for various chipsets
Jeff Johnson writes: > On 5/9/2024 9:37 AM, Jeff Johnson wrote: >> On 5/8/2024 9:50 PM, Kalle Valo wrote: >>> Sorry for the delay but finally I looked at this again. I decided to >>> just remove the fixme and otherwise it looks good for me. Please check >>> my changes: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=688130a66ed49f20ca0ce02c3987f6a474f7c93a >>> >> >> I have a question about the copyrights in the two new files: >> + * Copyright (c) 2018-2023, The Linux Foundation. All rights reserved. >> >> My understanding is that Qualcomm's affiliation with Linux Foundation via >> Code >> Aurora ended in December 2021, and hence any contributions in 2022-2023 >> should >> be the copyright of Qualcomm Innovation Center, Inc. >> >> > > ok it seems like Kalle's v13 had: > + * Copyright (c) 2018, The Linux Foundation. All rights reserved. > > and Ansuel's v14 has: > + * Copyright (c) 2018-2023, The Linux Foundation. All rights reserved. > > So Ansuel, is your work on behalf of The Linux Foundation? BTW in the pending branch I can change the copyright back to original so no need to resend because of this. But I'll need guidance from Ansuel. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v14] ath10k: add LED and GPIO controlling support for various chipsets
Christian Marangi writes: >> >> Sorry for the delay but finally I looked at this again. I decided to >> just remove the fixme and otherwise it looks good for me. Please check >> my changes: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=688130a66ed49f20ca0ce02c3987f6a474f7c93a >> > > All ok for me, Just I notice the ATH10K_LEDS is not exposed anymore? Is > that intended? Yes. It follows the same idea as other wireless drivers do, for example iwlwifi: config IWLWIFI_LEDS bool depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211 depends on IWLMVM || IWLDVM select LEDS_TRIGGERS select MAC80211_LEDS default y So what this patch now does: config ATH10K_LEDS bool depends on ATH10K depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211 default y The idea being that if LEDS_CLASS is enabled then ATH10K_LEDS is automatically enabled. But please let us know if something is wrong here. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v14] ath10k: add LED and GPIO controlling support for various chipsets
Ansuel Smith writes: > Il giorno sab 17 giu 2023 alle ore 19:28 Christian Marangi > ha scritto: > >> >> On Fri, Jun 16, 2023 at 01:35:04PM +0200, Christian Marangi wrote: >> > On Fri, Jun 16, 2023 at 08:03:23PM +0300, Kalle Valo wrote: >> > > Christian Marangi writes: >> > > >> > > > From: Sebastian Gottschall >> > > > >> > > > Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 >> > > > based chipsets with on chipset connected led's using WMI Firmware API. >> > > > The LED device will get available named as "ath10k-phyX" at sysfs and >> > > > can be controlled with various triggers. >> > > > Adds also debugfs interface for gpio control. >> > > > >> > > > Signed-off-by: Sebastian Gottschall >> > > > Reviewed-by: Steve deRosier >> > > > [kvalo: major reorg and cleanup] >> > > > Signed-off-by: Kalle Valo >> > > > [ansuel: rebase and small cleanup] >> > > > Signed-off-by: Christian Marangi >> > > > Tested-by: Stefan Lippers-Hollmann >> > > > --- >> > > > >> > > > Hi, >> > > > this is a very old patch from 2018 that somehow was talked till 2020 >> > > > with Kavlo asked to rebase and resubmit and nobody did. >> > > > So here we are in 2023 with me trying to finally have this upstream. >> > > > >> > > > A summarize of the situation. >> > > > - The patch is from years in OpenWRT. Used by anything that has ath10k >> > > > card and a LED connected. >> > > > - This patch is also used by the fw variant from Candela Tech with no >> > > > problem reported. >> > > > - It was pointed out that this caused some problem with ipq4019 SoC >> > > > but the problem was actually caused by a different bug related to >> > > > interrupts. >> > > > >> > > > I honestly hope we can have this feature merged since it's really >> > > > funny to have something that was so near merge and jet still not >> > > > present and with devices not supporting this simple but useful >> > > > feature. >> > > >> > > Indeed, we should finally get this in. Thanks for working on it. >> > > >> > > I did some minor changes to the patch, they are in my pending branch: >> > > >> > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=686464864538158f22842dc49eddea6fa50e59c1 >> > > >> > > My comments below, please review my changes. No need to resend because >> > > of these. >> > > >> > >> > Hi, >> > very happy this is going further. >> > >> > > > --- a/drivers/net/wireless/ath/ath10k/Kconfig >> > > > +++ b/drivers/net/wireless/ath/ath10k/Kconfig >> > > > @@ -67,6 +67,23 @@ config ATH10K_DEBUGFS >> > > > >> > > > If unsure, say Y to make it easier to debug problems. >> > > > >> > > > +config ATH10K_LEDS >> > > > + bool "Atheros ath10k LED support" >> > > > + depends on ATH10K >> > > > + select MAC80211_LEDS >> > > > + select LEDS_CLASS >> > > > + select NEW_LEDS >> > > > + default y >> > > > + help >> > > > + This option enables LEDs support for chipset LED pins. >> > > > + Each pin is connected via GPIO and can be controlled using >> > > > + WMI Firmware API. >> > > > + >> > > > + The LED device will get available named as "ath10k-phyX" at sysfs >> > > > and >> > > > + can be controlled with various triggers. >> > > > + >> > > > + Say Y, if you have LED pins connected to the ath10k wireless card. >> > > >> > > I'm not sure anymore if we should ask anything from the user, better to >> > > enable automatically if LED support is enabled in the kernel. So I >> > > simplified this to: >> > > >> > > config ATH10K_LEDS >> > > bool >> > > depends on ATH10K >> > > depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211 >> > > default y >> > > >> > > This follows what mt76 does: >> > > >>
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. Thanks. Please check that my modifications in the pending branch are correct: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=3aec20a8e797b28d32e75291cc070d5913bf6dab https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=df5b4bec31b0736a453d507762c5b3d098d5c733 I can freely edit commits in the pending branch, it's just a temporary branch for testing. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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: 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
Re: pull-request: ath-next-20240502
Kalle Valo wrote: > Hi, > > Please pull, more information in the tag below. > > Kalle > > The following changes since commit 57a03d83f229126b0aab6f305821358755c7b130: > > Merge branch 'mlxsw-preparations-for-improving-performance' (2024-04-03 > 19:50:44 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git > tags/ath-next-20240502 > > for you to fetch changes up to bf76b144fe53c7f0de9e294947d903fc7724776f: > > wifi: ath12k: fix the problem that down grade phy mode operation > (2024-05-02 13:15:38 +0300) > > > ath.git patches for v6.10 > > ath12k > > * debugfs support > > * dfs_simulate_radar debugfs file > > * disable Wireless Extensions > > * suspend and hibernation support > > * ACPI support > > * refactoring in preparation of multi-link support > > ath11k > > * support hibernation (required changes in qrtr and MHI subsystems) > > * ieee80211-freq-limit Device Tree property support > > ath10k > > * firmware-name Device Tree property support > > > Arnd Bergmann (2): > wifi: carl9170: re-fix fortified-memset warning > wifi: ath9k: work around memset overflow warning > > Baochen Qiang (16): > bus: mhi: host: Add mhi_power_down_keep_dev() API to support system > suspend/hibernation > net: qrtr: support suspend/hibernation > wifi: ath11k: support hibernation > wifi: ath12k: fix kernel crash during resume > wifi: ath12k: rearrange IRQ enable/disable in reset path > wifi: ath12k: remove MHI LOOPBACK channels > wifi: ath12k: do not dump SRNG statistics during resume > wifi: ath12k: fix warning on DMA ring capabilities event > wifi: ath12k: decrease MHI channel buffer length to 8KB > wifi: ath12k: flush all packets before suspend > wifi: ath12k: no need to handle pktlog during suspend/resume > wifi: ath12k: avoid stopping mac80211 queues in ath12k_core_restart() > wifi: ath12k: support suspend/resume > wifi: ath12k: change supports_suspend to true for WCN7850 > wifi: ath12k: check M3 buffer size as well whey trying to reuse it > wifi: ath12k: fix flush failure in recovery scenarios > > Christian Lamparter (2): > dt-bindings: net: wireless: ath11k: add ieee80211-freq-limit property > wifi: ath11k: add support DT ieee80211-freq-limit > > Christophe JAILLET (1): > wifi: ath11k: Fix error handling in ath11k_wmi_p2p_noa_event() > > Dmitry Baryshkov (5): > dt-bindings: net: wireless: ath10k: describe firmware-name property > wifi: ath10k: support board-specific firmware overrides > wifi: ath10k: populate board data for WCN3990 > wifi: ath10k: drop chip-specific board data file name > wifi: ath10k: drop fw.eboard file name > > Gustavo A. R. Silva (2): > wifi: wil6210: cfg80211: Use __counted_by() in struct > wmi_start_scan_cmd and avoid some -Wfamnae warnings > wifi: wil6210: wmi: Use __counted_by() in struct > wmi_set_link_monitor_cmd and avoid -Wfamnae warning > > Jeff Johnson (3): > wifi: ath11k: fix hal_rx_buf_return_buf_manager documentation > wifi: ath12k: fix hal_rx_buf_return_buf_manager documentation > wifi: ath12k: don't use %pK in dmesg format strings > > Kalle Valo (2): > Merge branch 'mhi-immutable' of > git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi into ath-next > wifi: ath12k: enable WIPHY_FLAG_DISABLE_WEXT > > Kang Yang (2): > wifi: ath12k: dynamically update peer puncturing bitmap for STA > wifi: ath12k: add support to handle beacon miss for WCN7850 > > Karthikeyan Kathirvel (1): > wifi: ath12k: fix out-of-bound access of qmi_invoke_handler() > > Karthikeyan Periyasamy (9): > wifi: ath12k: extend the link capable flag > wifi: ath12k: fix link capable flags > wifi: ath12k: correct the capital word typo > wifi: ath12k: add multiple radio support in a single MAC HW un/register > wifi: ath12k: fix mac id extraction when MSDU spillover in rx error path > wifi: ath12k: avoid redundant code in Rx cookie conversion init > wifi: ath12k: Refactor the hardware cookie conversion init > wifi: ath12k: displace the Tx and Rx descriptor in cookie conversion > table > wifi: ath12k: Refactor data path cmem init > > Krzysztof Kozlowski (1): > wifi: ath6kl: sdio: simplify module initialization > > Lingbo
pull-request: ath-next-20240502
Hi, Please pull, more information in the tag below. Kalle The following changes since commit 57a03d83f229126b0aab6f305821358755c7b130: Merge branch 'mlxsw-preparations-for-improving-performance' (2024-04-03 19:50:44 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git tags/ath-next-20240502 for you to fetch changes up to bf76b144fe53c7f0de9e294947d903fc7724776f: wifi: ath12k: fix the problem that down grade phy mode operation (2024-05-02 13:15:38 +0300) ath.git patches for v6.10 ath12k * debugfs support * dfs_simulate_radar debugfs file * disable Wireless Extensions * suspend and hibernation support * ACPI support * refactoring in preparation of multi-link support ath11k * support hibernation (required changes in qrtr and MHI subsystems) * ieee80211-freq-limit Device Tree property support ath10k * firmware-name Device Tree property support Arnd Bergmann (2): wifi: carl9170: re-fix fortified-memset warning wifi: ath9k: work around memset overflow warning Baochen Qiang (16): bus: mhi: host: Add mhi_power_down_keep_dev() API to support system suspend/hibernation net: qrtr: support suspend/hibernation wifi: ath11k: support hibernation wifi: ath12k: fix kernel crash during resume wifi: ath12k: rearrange IRQ enable/disable in reset path wifi: ath12k: remove MHI LOOPBACK channels wifi: ath12k: do not dump SRNG statistics during resume wifi: ath12k: fix warning on DMA ring capabilities event wifi: ath12k: decrease MHI channel buffer length to 8KB wifi: ath12k: flush all packets before suspend wifi: ath12k: no need to handle pktlog during suspend/resume wifi: ath12k: avoid stopping mac80211 queues in ath12k_core_restart() wifi: ath12k: support suspend/resume wifi: ath12k: change supports_suspend to true for WCN7850 wifi: ath12k: check M3 buffer size as well whey trying to reuse it wifi: ath12k: fix flush failure in recovery scenarios Christian Lamparter (2): dt-bindings: net: wireless: ath11k: add ieee80211-freq-limit property wifi: ath11k: add support DT ieee80211-freq-limit Christophe JAILLET (1): wifi: ath11k: Fix error handling in ath11k_wmi_p2p_noa_event() Dmitry Baryshkov (5): dt-bindings: net: wireless: ath10k: describe firmware-name property wifi: ath10k: support board-specific firmware overrides wifi: ath10k: populate board data for WCN3990 wifi: ath10k: drop chip-specific board data file name wifi: ath10k: drop fw.eboard file name Gustavo A. R. Silva (2): wifi: wil6210: cfg80211: Use __counted_by() in struct wmi_start_scan_cmd and avoid some -Wfamnae warnings wifi: wil6210: wmi: Use __counted_by() in struct wmi_set_link_monitor_cmd and avoid -Wfamnae warning Jeff Johnson (3): wifi: ath11k: fix hal_rx_buf_return_buf_manager documentation wifi: ath12k: fix hal_rx_buf_return_buf_manager documentation wifi: ath12k: don't use %pK in dmesg format strings Kalle Valo (2): Merge branch 'mhi-immutable' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi into ath-next wifi: ath12k: enable WIPHY_FLAG_DISABLE_WEXT Kang Yang (2): wifi: ath12k: dynamically update peer puncturing bitmap for STA wifi: ath12k: add support to handle beacon miss for WCN7850 Karthikeyan Kathirvel (1): wifi: ath12k: fix out-of-bound access of qmi_invoke_handler() Karthikeyan Periyasamy (9): wifi: ath12k: extend the link capable flag wifi: ath12k: fix link capable flags wifi: ath12k: correct the capital word typo wifi: ath12k: add multiple radio support in a single MAC HW un/register wifi: ath12k: fix mac id extraction when MSDU spillover in rx error path wifi: ath12k: avoid redundant code in Rx cookie conversion init wifi: ath12k: Refactor the hardware cookie conversion init wifi: ath12k: displace the Tx and Rx descriptor in cookie conversion table wifi: ath12k: Refactor data path cmem init Krzysztof Kozlowski (1): wifi: ath6kl: sdio: simplify module initialization Lingbo Kong (5): wifi: ath12k: ACPI TAS support wifi: ath12k: ACPI SAR support wifi: ath12k: ACPI CCA threshold support wifi: ath12k: ACPI band edge channel power support wifi: ath12k: fix the problem that down grade phy mode operation Miaoqing Pan (1): wifi: ath12k: fix missing endianness conversion in wmi_vdev_create_cmd() Nikita Zhandarovich (2): wifi: carl9170: add a proper sanity check for endpoints wifi: ar5523: enable proper endpoint verification Raj Kumar Bhagat (2): wifi: ath12k: read single_chip_mlo_support parameter from QMI PHY capability wifi: ath12k: set mlo_capable_flags ba
Re: [PATCH v3 1/3] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Bjorn Andersson writes: > 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. > 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. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
Eric Park writes: > On 2024-04-29 14:18, Kalle Valo wrote: >> If you run wpa_supplicant -dddt (or similar) you get a lot of debug >> output, I'm sure it will also include the cipher. > > Good to know, thank you. Will keep this in mind the next time I'm > troubleshooting WPA-levels. > >> Very good that you found this is 802.11w related. What is the make and >> model of your router? > > I'm using a GL-AXT1800 (Slate AX) router from GL.iNet. > >> I don't know how well ath10k 802.11w support is tested and then it was >> last tested. Do you happen to have other Access Points supporting >> 802.11w? That might help to pinpoint if 802.11w is completely broken in >> ath10k or if this is an interoperability issue with ath10k and your AP. > > I unfortunately do not have access to any other routers I can modify > settings on at the moment (or any other APs to connect to, to test on, > really...) I may have some routers to test it on next week, but I'm > unsure whether they allow me to modify the 802.11w settings as they're > mostly proprietary and don't run something like OpenWRT. > > Do you know if it'll be possible to add a flag to enable/disable 802.11w > on ath10k's side? Even if it turns out to be an interoperability issue, > it will most likely be useful to have the ability to switch it off for > APs that don't play nice. Especially for public APs and proprietary > APs where the end-user can't realistically turn off 802.11w for the > entire network. If the problem is on ath10k side I would rather semove support for 802.11w altogether (until it's fixed). It's controlled with this flag: ieee80211_hw_set(ar->hw, MFP_CAPABLE); Alternatively if it works on some hardware and not on others we could make it per hw, for example disabled on QCA6174 and enabled on all others. But I found some old documentation claiming that 802.11w can be disabled from Network Manager, if it works that sounds like a good temporary solution: "pmf int32 0 Indicates whether Protected Management Frames (802.11w) must be enabled for the connection." https://developer-old.gnome.org/NetworkManager/stable/settings-802-11-wireless-security.html -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
Eric Park writes: > On 4/25/24 5:51 AM, Kalle Valo wrote: > >> 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: >> >> (...) > > I had some time today to test this, but unfortunately I couldn't > figure out if wpa_supplicant was using WPA2 or WPA3. Trying to connect > via `key_mgmt=SAE` caused `dhcpcd` to time out looking for carriers, > so I guess it was connecting via WPA2. In any case the speed results > were the same as disabling WPA3 on the router-side. If you run wpa_supplicant -dddt (or similar) you get a lot of debug output, I'm sure it will also include the cipher. > The reason I'm sending this email despite not making much progress > above is because it turns out I was chasing a red herring. The real > problem behind the degraded throughput was 802.11w. The router was > advertising support for it (802.11w capable but optional), but was not > forcing clients that didn't have the capability (required mode). > > In Optional mode, I was experiencing the degraded performance. But > after I disabled 802.11w on the router side, the speeds recovered to > normal levels on both 2.4 GHz and 5 GHz bands, even connected over > WPA3. > > So I'm guessing something on the driver's side is signaling that it > supports 802.11w, when in reality it doesn't or some bug with the > implementation causes the speed to drop. Or maybe there's an overhead > I'm unaware of when 802.11w is enabled? My limited understanding of > 802.11w is that the management frames are protected to prevent deauth > attacks. > > I'm not sure where to begin troubleshooting this, but in the interim > can I disable the capability advertising on the driver-level? I don't > want to disable 802.11w on my entire network, if possible. Very good that you found this is 802.11w related. What is the make and model of your router? I don't know how well ath10k 802.11w support is tested and then it was last tested. Do you happen to have other Access Points supporting 802.11w? That might help to pinpoint if 802.11w is completely broken in ath10k or if this is an interoperability issue with ath10k and your AP. -- 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
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
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 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
Re: [PATCH wireless v2] wifi: ath10k: Fix an error code problem in ath10k_dbg_sta_write_peer_debug_trigger()
Su Hui wrote:
> Clang Static Checker (scan-build) warns:
>
> drivers/net/wireless/ath/ath10k/debugfs_sta.c:line 429, column 3
> Value stored to 'ret' is never read.
>
> Return 'ret' rather than 'count' when 'ret' stores an error code.
>
> Fixes: ee8b08a1be82 ("ath10k: add debugfs support to get per peer tids log
> via tracing")
> Signed-off-by: Su Hui
> Acked-by: Jeff Johnson
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
c511a9c12674 wifi: ath10k: Fix an error code problem in
ath10k_dbg_sta_write_peer_debug_trigger()
--
https://patchwork.kernel.org/project/linux-wireless/patch/20240422034243.938962-1-su...@nfschina.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next v7 10/10] wifi: ath11k: allocate dummy net_device dynamically
Breno Leitao writes: > Embedding net_device into structures prohibits the usage of flexible > arrays in the net_device structure. For more details, see the discussion > at [1]. > > Un-embed the net_device from struct ath11k_ext_irq_grp by converting it > into a pointer. Then use the leverage alloc_netdev() to allocate the > net_device object at ath11k_ahb_config_ext_irq() for ahb, and > ath11k_pcic_ext_irq_config() for pcic. > > The free of the device occurs at ath11k_ahb_free_ext_irq() for the ahb > case, and ath11k_pcic_free_ext_irq() for the pcic case. > > [1] https://lore.kernel.org/all/20240229225910.79e22...@kernel.org/ > > Signed-off-by: Breno Leitao > Tested-by: Kalle Valo I assume this goes via net-next: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next v7 09/10] wifi: ath10k: allocate dummy net_device dynamically
Breno Leitao writes: > Embedding net_device into structures prohibits the usage of flexible > arrays in the net_device structure. For more details, see the discussion > at [1]. > > Un-embed the net_device from struct ath10k by converting it > into a pointer. Then use the leverage alloc_netdev() to allocate the > net_device object at ath10k_core_create(). The free of the device occurs > at ath10k_core_destroy(). > > [1] https://lore.kernel.org/all/20240229225910.79e22...@kernel.org/ > > Signed-off-by: Breno Leitao I assume this goes via net-next: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next v7 08/10] wifi: qtnfmac: Use netdev dummy allocator helper
Breno Leitao writes:
> There is a new dummy netdev allocator, use it instead of
> alloc_netdev()/init_dummy_netdev combination.
>
> Using alloc_netdev() with init_dummy_netdev might cause some memory
> corruption at the driver removal side.
>
> Fixes: 61cdb09ff760 ("wifi: qtnfmac: allocate dummy net_device dynamically")
> Signed-off-by: Breno Leitao
I assume this goes via net-next:
Acked-by: Kalle Valo
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH wireless v2] wifi: ath10k: Fix an error code problem in ath10k_dbg_sta_write_peer_debug_trigger()
Su Hui writes:
> Clang Static Checker (scan-build) Warning:
> drivers/net/wireless/ath/ath10k/debugfs_sta.c:line 429, column 3
> Value stored to 'ret' is never read.
>
> Return 'ret' rather than 'count' when 'ret' stores an error code.
> By the way, remove some useless code.
>
> Fixes: ee8b08a1be82 ("ath10k: add debugfs support to get per peer tids log
> via tracing")
> Signed-off-by: Su Hui
> ---
> v2:
> - remove the initializer change.
>
> drivers/net/wireless/ath/ath10k/debugfs_sta.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> index 394bf3c32abf..c1198e9027ae 100644
> --- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> +++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
> @@ -432,14 +432,12 @@ ath10k_dbg_sta_write_peer_debug_trigger(struct file
> *file,
>
> ret = ath10k_wmi_peer_set_param(ar, arsta->arvif->vdev_id, sta->addr,
> ar->wmi.peer_param->debug,
> peer_debug_trigger);
> - if (ret) {
> + if (ret)
> ath10k_warn(ar, "failed to set param to trigger peer tid logs
> for station ret: %d\n",
> ret);
> - goto out;
> - }
Minimal changes with one logical change per patch, please. I'll remove
this part in the pending branch.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH net-next v5 00/10] allocate dummy device dynamically
Breno Leitao writes:
> struct net_device shouldn't be embedded into any structure, instead,
> the owner should use the private space to embed their state into
> net_device.
>
> But, in some cases the net_device is embedded inside the private
> structure, which blocks the usage of zero-length arrays inside
> net_device.
>
> Create a helper to allocate a dummy device at dynamically runtime, and
> move the Ethernet devices to use it, instead of embedding the dummy
> device inside the private structure.
>
> This fixes all the network cases plus some wireless drivers.
>
> PS: Due to lack of hardware, unfortunately most these patches are
> compiled tested only, except ath11k that was kindly tested by Kalle Valo.
>
> ---
> Changelog:
>
> v1:
> * https://lore.kernel.org/all/20240327200809.512867-1-lei...@debian.org/
>
> v2:
> * Patch 1: Use a pre-defined name ("dummy#") for the dummy
> net_devices.
> * Patch 2-5: Added users for the new helper.
> v3:
> * Use free_netdev() instead of kfree() as suggested by Jakub.
> * Change the free_netdev() place in ipa driver, as suggested by
> Alex Elder.
> * Set err in the error path in the Marvell driver, as suggested
> by Simon Horman.
> v4:
> * Added a new patch to add dummy device at free_netdev(), as suggested
> by Jakub.
> * Added support for some wireless driver.
> * Added some Acked-by and Reviewed-by.
> v5:
> * Added a new patch to fix some typos in the previous code,
> suggested by Ido.
> * Rebased to net-net/main
I'm nitpicking here but I prefer to have the changelog in reverse order,
that is v5 first and v1 last. I'm most interested about the changes in
v5, I don't care about v1 at this point. Though I don't know if net
folks have a different prefence, just wanted to mention this.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/3] wifi: Un-embed ath10k and ath11k dummy netdev
Breno Leitao writes: > On Tue, Apr 09, 2024 at 01:03:21PM +0300, Kalle Valo wrote: > >> Breno Leitao writes: >> >> >> > Reading the issue, I am afraid that freeing netdev explicitly >> >> > (free_netdev()) might not be the best approach at the exit path. >> >> > >> >> > I would like to try to leverage the ->needs_free_netdev netdev >> >> > mechanism to do the clean-up, if that makes sense. I've updated the >> >> > ath11k patch, and I am curious if that is what we want. >> >> > >> >> > Would you mind testing a net patch I have, please? >> >> > >> >> > https://github.com/leitao/linux/tree/wireless-dummy_v2 >> >> >> >> I tested this again with my WCN6855 hw2.0 x86 test box on this commit: >> >> >> >> a87674ac820e wifi: ath11k: allocate dummy net_device dynamically >> >> >> >> It passes my tests and doesn't crash, but I see this kmemleak warning a >> >> lot: >> > >> > Thanks Kalle, that was helpful. The device is not being clean-up >> > automatically. >> > >> > Chatting with Jakub, he suggested coming back to the original approach, >> > but, adding a additional patch, at the free_netdev(). >> > >> > Would you mind running another test, please? >> > >> >https://github.com/leitao/linux/tree/wireless-dummy_v3 >> > >> > The branch above is basically the original branch (as in this patch >> > series), with this additional patch: >> > >> >Author: Breno Leitao >> >Date: Mon Apr 8 11:37:32 2024 -0700 >> > >> >net: free_netdev: exit earlier if dummy >> >> I tested with the same ath11k hardware and this one passes all my >> (simple) ath11k tests, no issues found. I used this commit: >> >> 1c10aebaa8ce net: free_netdev: exit earlier if dummy > > Thank you so much for the test. > > I will respin a v2 of this patchset with the additional patch included. Sounds good. Feel free to add: Tested-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/3] wifi: Un-embed ath10k and ath11k dummy netdev
Breno Leitao writes: >> > Reading the issue, I am afraid that freeing netdev explicitly >> > (free_netdev()) might not be the best approach at the exit path. >> > >> > I would like to try to leverage the ->needs_free_netdev netdev >> > mechanism to do the clean-up, if that makes sense. I've updated the >> > ath11k patch, and I am curious if that is what we want. >> > >> > Would you mind testing a net patch I have, please? >> > >> > https://github.com/leitao/linux/tree/wireless-dummy_v2 >> >> I tested this again with my WCN6855 hw2.0 x86 test box on this commit: >> >> a87674ac820e wifi: ath11k: allocate dummy net_device dynamically >> >> It passes my tests and doesn't crash, but I see this kmemleak warning a >> lot: > > Thanks Kalle, that was helpful. The device is not being clean-up > automatically. > > Chatting with Jakub, he suggested coming back to the original approach, > but, adding a additional patch, at the free_netdev(). > > Would you mind running another test, please? > > https://github.com/leitao/linux/tree/wireless-dummy_v3 > > The branch above is basically the original branch (as in this patch > series), with this additional patch: > > Author: Breno Leitao > Date: Mon Apr 8 11:37:32 2024 -0700 > > net: free_netdev: exit earlier if dummy I tested with the same ath11k hardware and this one passes all my (simple) ath11k tests, no issues found. I used this commit: 1c10aebaa8ce net: free_netdev: exit earlier if dummy -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/3] wifi: Un-embed ath10k and ath11k dummy netdev
Breno Leitao writes: > Hello Kalle, > > On Fri, Apr 05, 2024 at 06:15:05PM +0300, Kalle Valo wrote: >> Breno Leitao writes: >> >> > struct net_device shouldn't be embedded into any structure, instead, >> > the owner should use the private space to embed their state into >> > net_device. >> > >> > This patch set fixes the problem above for ath10k and ath11k. This also >> > fixes the conversion of qtnfmac driver to the new helper. >> > >> > This patch set depends on a series that is still under review: >> > https://lore.kernel.org/all/20240404114854.2498663-1-lei...@debian.org/#t >> > >> > If it helps, I've pushed the tree to >> > https://github.com/leitao/linux/tree/wireless-dummy >> > >> > PS: Due to lack of hardware, unfortunately all these patches are >> > compiled tested only. >> > >> > Breno Leitao (3): >> > wifi: qtnfmac: Use netdev dummy allocator helper >> > wifi: ath10k: allocate dummy net_device dynamically >> > wifi: ath11k: allocate dummy net_device dynamically >> >> Thanks for setting up the branch, that makes the testing very easy. I >> now tested the branch using the commit below with ath11k WCN6855 hw2.0 >> on an x86 box: >> >> 5be9a125d8e7 wifi: ath11k: allocate dummy net_device dynamically >> >> But unfortunately it crashes, the stack trace below. I can easily test >> your branches, just let me know what to test. A direct 'git pull' >> command is the best. > > Thanks for the test. > > Reading the issue, I am afraid that freeing netdev explicitly > (free_netdev()) might not be the best approach at the exit path. > > I would like to try to leverage the ->needs_free_netdev netdev > mechanism to do the clean-up, if that makes sense. I've updated the > ath11k patch, and I am curious if that is what we want. > > Would you mind testing a net patch I have, please? > > https://github.com/leitao/linux/tree/wireless-dummy_v2 I tested this again with my WCN6855 hw2.0 x86 test box on this commit: a87674ac820e wifi: ath11k: allocate dummy net_device dynamically It passes my tests and doesn't crash, but I see this kmemleak warning a lot: unreferenced object 0x888127109400 (size 128): comm "insmod", pid 2813, jiffies 4294926528 hex dump (first 32 bytes): d0 93 d5 0a 81 88 ff ff d0 93 d5 0a 81 88 ff ff 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace (crc 870e4f12): [] kmemleak_alloc+0x45/0x80 [] kmalloc_trace+0x278/0x2c0 [] __hw_addr_create+0x55/0x260 [] __hw_addr_add_ex+0x2fb/0x6d0 [] dev_addr_init+0x144/0x230 [] alloc_netdev_mqs+0x12e/0xfe0 [] alloc_netdev_dummy+0x25/0x30 [] ath11k_pcic_ext_irq_config+0x1ad/0xc10 [ath11k] [] ath11k_pcic_config_irq+0x2f1/0x4b0 [ath11k] [] ath11k_pci_probe+0x874/0x1210 [ath11k_pci] [] local_pci_probe+0xd6/0x180 [] pci_call_probe+0x15a/0x400 [] pci_device_probe+0xa6/0x100 [] really_probe+0x1d5/0x920 [] __driver_probe_device+0x2e8/0x3f0 [] driver_probe_device+0x4a/0x140 -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/3] wifi: Un-embed ath10k and ath11k dummy netdev
Breno Leitao writes: > struct net_device shouldn't be embedded into any structure, instead, > the owner should use the private space to embed their state into > net_device. > > This patch set fixes the problem above for ath10k and ath11k. This also > fixes the conversion of qtnfmac driver to the new helper. > > This patch set depends on a series that is still under review: > https://lore.kernel.org/all/20240404114854.2498663-1-lei...@debian.org/#t > > If it helps, I've pushed the tree to > https://github.com/leitao/linux/tree/wireless-dummy > > PS: Due to lack of hardware, unfortunately all these patches are > compiled tested only. > > Breno Leitao (3): > wifi: qtnfmac: Use netdev dummy allocator helper > wifi: ath10k: allocate dummy net_device dynamically > wifi: ath11k: allocate dummy net_device dynamically Thanks for setting up the branch, that makes the testing very easy. I now tested the branch using the commit below with ath11k WCN6855 hw2.0 on an x86 box: 5be9a125d8e7 wifi: ath11k: allocate dummy net_device dynamically But unfortunately it crashes, the stack trace below. I can easily test your branches, just let me know what to test. A direct 'git pull' command is the best. [ 238.886002] rmmod ath11k_pci [ 239.530328] [ cut here ] [ 239.530433] kernel BUG at net/core/dev.c:11066! [ 239.530621] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [ 239.530709] CPU: 5 PID: 1668 Comm: rmmod Not tainted 6.9.0-rc2+ #1367 [ 239.530762] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 239.530848] RIP: 0010:free_netdev (net/core/dev.c:11066 (discriminator 1)) [ 239.530893] Code: 08 84 d2 0f 85 3c 01 00 00 0f b7 83 3a 03 00 00 48 29 c3 48 89 df e8 27 10 21 fe 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 44 0f b6 25 fd 91 53 02 41 80 fc 01 0f 87 1f 14 94 00 41 83 All code 0: 08 84 d2 0f 85 3c 01or %al,0x13c850f(%rdx,%rdx,8) 7: 00 00 add%al,(%rax) 9: 0f b7 83 3a 03 00 00movzwl 0x33a(%rbx),%eax 10: 48 29 c3sub%rax,%rbx 13: 48 89 dfmov%rbx,%rdi 16: e8 27 10 21 fe call 0xfe211042 1b: 48 83 c4 10 add$0x10,%rsp 1f: 5b pop%rbx 20: 41 5c pop%r12 22: 41 5d pop%r13 24: 41 5e pop%r14 26: 41 5f pop%r15 28: 5d pop%rbp 29: c3 ret 2a:* 0f 0b ud2 <-- trapping instruction 2c: 44 0f b6 25 fd 91 53movzbl 0x25391fd(%rip),%r12d# 0x2539231 33: 02 34: 41 80 fc 01 cmp$0x1,%r12b 38: 0f 87 1f 14 94 00 ja 0x94145d 3e: 41 rex.B 3f: 83 .byte 0x83 Code starting with the faulting instruction === 0: 0f 0b ud2 2: 44 0f b6 25 fd 91 53movzbl 0x25391fd(%rip),%r12d# 0x2539207 9: 02 a: 41 80 fc 01 cmp$0x1,%r12b e: 0f 87 1f 14 94 00 ja 0x941433 14: 41 rex.B 15: 83 .byte 0x83 [ 239.530977] RSP: 0018:c90002dffb70 EFLAGS: 00010202 [ 239.531023] RAX: 0005 RBX: 88810c819000 RCX: [ 239.531072] RDX: 1110219032d1 RSI: 87e79780 RDI: [ 239.531120] RBP: c90002dffba8 R08: 0001 R09: 0001 [ 239.531169] R10: 897e3f17 R11: 00bb R12: 88810c8194e0 [ 239.531224] R13: 88810c819178 R14: dc00 R15: 88810c819688 [ 239.531274] FS: 7f462c4c4740() GS:888232c0() knlGS: [ 239.531326] CS: 0010 DS: ES: CR0: 80050033 [ 239.531371] CR2: 55fc93483308 CR3: 000113a99004 CR4: 003706f0 [ 239.531420] Call Trace: [ 239.531484] [ 239.531550] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 239.531592] ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) [ 239.531630] ? do_trap (arch/x86/kernel/traps.c:114 arch/x86/kernel/traps.c:155) [ 239.531669] ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:176) [ 239.531708] ? free_netdev (net/core/dev.c:11066 (discriminator 1)) [ 239.531749] ? handle_invalid_op (arch/x86/kernel/traps.c:214) [ 239.531789] ? free_netdev (net/core/dev.c:11066 (discriminator 1)) [ 239.531829] ? exc_invalid_op (arch/x86/kernel/traps.c:267) [ 239.531868] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 239.531910] ? free_netdev (net/core/dev.c:11066 (discriminator 1)) [ 239.531952] ath11k_pcic_free_irq (drivers/net/wireless/ath/ath11k/pcic.c:312 (discriminator 2) drivers/net/wirele
Re: [PATCH 0/3] wifi: ath10k: fix board file loading for wcn3990 devices
Dmitry Baryshkov writes: > On Fri, 5 Apr 2024 at 14:57, Kalle Valo wrote: > >> >> Dmitry Baryshkov writes: >> >> > On Tue, 30 Jan 2024 at 08:47, Dmitry Baryshkov >> > wrote: >> > >> >> >> >> The ath10k driver fails to properly handle fallback from board-2.bin to >> >> board.bin for WCN3990 cards. This happens because the >> >> ath10k_hw_params_list doesn't include .fw.board* parameters for the >> >> WCN3990 platform. >> >> >> >> Add board data configuration for WCN3990. While we are at it, merge >> >> common pieces of BDF support: drop .board and .eboard names from struct >> >> ath10k_hw_params_fw and use the common name instead. >> >> >> >> Signed-off-by: Dmitry Baryshkov >> >> --- >> >> Dmitry Baryshkov (3): >> >> wifi: ath10k: populate board data for WCN3990 >> >> wifi: ath10k: drop chip-specific board data file name >> >> wifi: ath10k: drop fw.eboard file name >> >> >> >> drivers/net/wireless/ath/ath10k/core.c | 32 >> >> - >> >> drivers/net/wireless/ath/ath10k/hw.h| 14 ++--- >> >> drivers/net/wireless/ath/ath10k/pci.c | 10 - >> >> drivers/net/wireless/ath/ath10k/targaddrs.h | 3 +++ >> >> 4 files changed, 14 insertions(+), 45 deletions(-) >> >> --- >> >> base-commit: 596764183be8ebb13352b281a442a1f1151c9b06 >> >> change-id: 20240129-wcn3990-board-fw-a2d97507a712 >> > >> > Kalle, Jeff, is there anything pending on me on this series? >> >> This is in my queue (Deferred state): >> >> https://patchwork.kernel.org/project/linux-wireless/list/?series=821157&state=*&order=date >> >> Unfortunately there is not really much time for ath10k nowadays so there >> will be delays. > > No problems, each maintainer treats PW states slightly differently, so > I was trying to understand if there is anything left on my side. That's true. I have tried to document how we in wireless use patchwork here: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork Though I guess I'm the only one using Deferred state. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RFC v2 0/4] wifi: ath10k: support board-specific firmware overrides
Dmitry Baryshkov writes: > On Fri, 5 Apr 2024 at 15:01, Kalle Valo wrote: > >> >> Dmitry Baryshkov writes: >> >> > On Fri, 8 Mar 2024 at 17:19, Kalle Valo wrote: >> >> >> >> Dmitry Baryshkov writes: >> >> >> >> >> To be on the safe side using 'qcom-rb1' makes sense but on the other >> >> >> hand that means we need to update linux-firmware (basically add a new >> >> >> symlink) everytime a new product is added. But are there going to be >> >> >> that many new ath10k based products? >> >> >> >> >> >> Using 'qcm2290' is easier because for a new product then there only >> >> >> needs to be a change in DTS and no need to change anything >> >> >> linux-firmware. But here the risk is that if there's actually two >> >> >> different ath10k firmware branches for 'qcm2290'. If that ever happens >> >> >> (I hope not) I guess we could solve that by adding new 'qcm2290-foo' >> >> >> directory? >> >> >> >> >> >> But I don't really know, thoughts? >> >> > >> >> > After some thought, I'd suggest to follow approach taken by the rest >> >> > of qcom firmware: >> >> >> >> Can you provide pointers to those cases? >> > >> > https://gitlab.com/kernel-firmware/linux-firmware/-/tree/main/qcom/sc8280xp/LENOVO/21BX >> > >> >> >> >> > put a default (accepted by non-secured hardware) firmware to SoC dir >> >> > and then put a vendor-specific firmware into subdir. If any of such >> >> > vendors appear, we might even implement structural fallback: first >> >> > look into sdm845/Google/blueline, then in sdm845/Google, sdm845/ and >> >> > finally just under hw1.0. >> >> >> >> Honestly that looks quite compilicated compared to having just one >> >> sub-directory. How will ath10k find the directory names (or I vendor and >> >> model names) like 'Google' or 'blueline' in this example? >> > >> > I was thinking about the firmware-name = "sdm845/Google/blueline". But >> > this can be really simpler, firmware-name = "blueline" or >> > "sdm845/blueline" with no need for fallbacks. >> >> I have been also thinking about this and I would prefer not to have the >> fallbacks. But good if you agree with that. >> >> IMHO just "sdm845-blueline" would be the most simple. I don't see the >> point of having a directory structure when there are not that many >> directories really. But this is just cosmetics. > > It is "not many directories" if we are thinking about the > linux-firmware or open devices. But once embedded distros start > picking this up for the supported devices, this can quickly become a > nuisance. Ok. Just out of curiosity, any ideas how many devices/products are there with wcn3990 who want to use ath10k? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RFC v2 1/4] dt-bindings: net: wireless: ath10k: describe firmware-name property
Dmitry Baryshkov wrote: > For WCN3990 platforms we need to look for the platform / board specific > firmware-N.mbn file which corresponds to the wlanmdsp.mbn loaded to the > modem DSP via the TQFTPserv. Add firmware-name property describing this > classifier. > > Acked-by: Krzysztof Kozlowski > Signed-off-by: Dmitry Baryshkov > Signed-off-by: Kalle Valo 2 patches applied to ath-next branch of ath.git, thanks. 158fff51b4c3 dt-bindings: net: wireless: ath10k: describe firmware-name property 5abf259772df wifi: ath10k: support board-specific firmware overrides -- https://patchwork.kernel.org/project/linux-wireless/patch/20240306-wcn3990-firmware-path-v2-1-f89e98e71...@linaro.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RFC v2 0/4] wifi: ath10k: support board-specific firmware overrides
Dmitry Baryshkov writes: > On Fri, 8 Mar 2024 at 17:19, Kalle Valo wrote: >> >> Dmitry Baryshkov writes: >> >> >> To be on the safe side using 'qcom-rb1' makes sense but on the other >> >> hand that means we need to update linux-firmware (basically add a new >> >> symlink) everytime a new product is added. But are there going to be >> >> that many new ath10k based products? >> >> >> >> Using 'qcm2290' is easier because for a new product then there only >> >> needs to be a change in DTS and no need to change anything >> >> linux-firmware. But here the risk is that if there's actually two >> >> different ath10k firmware branches for 'qcm2290'. If that ever happens >> >> (I hope not) I guess we could solve that by adding new 'qcm2290-foo' >> >> directory? >> >> >> >> But I don't really know, thoughts? >> > >> > After some thought, I'd suggest to follow approach taken by the rest >> > of qcom firmware: >> >> Can you provide pointers to those cases? > > https://gitlab.com/kernel-firmware/linux-firmware/-/tree/main/qcom/sc8280xp/LENOVO/21BX > >> >> > put a default (accepted by non-secured hardware) firmware to SoC dir >> > and then put a vendor-specific firmware into subdir. If any of such >> > vendors appear, we might even implement structural fallback: first >> > look into sdm845/Google/blueline, then in sdm845/Google, sdm845/ and >> > finally just under hw1.0. >> >> Honestly that looks quite compilicated compared to having just one >> sub-directory. How will ath10k find the directory names (or I vendor and >> model names) like 'Google' or 'blueline' in this example? > > I was thinking about the firmware-name = "sdm845/Google/blueline". But > this can be really simpler, firmware-name = "blueline" or > "sdm845/blueline" with no need for fallbacks. I have been also thinking about this and I would prefer not to have the fallbacks. But good if you agree with that. IMHO just "sdm845-blueline" would be the most simple. I don't see the point of having a directory structure when there are not that many directories really. But this is just cosmetics. > My point is that the firmware-name provides the possibility to handle > that in different ways. Very good, thanks. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/3] wifi: ath10k: fix board file loading for wcn3990 devices
Dmitry Baryshkov writes: > On Tue, 30 Jan 2024 at 08:47, Dmitry Baryshkov > wrote: > >> >> The ath10k driver fails to properly handle fallback from board-2.bin to >> board.bin for WCN3990 cards. This happens because the >> ath10k_hw_params_list doesn't include .fw.board* parameters for the >> WCN3990 platform. >> >> Add board data configuration for WCN3990. While we are at it, merge >> common pieces of BDF support: drop .board and .eboard names from struct >> ath10k_hw_params_fw and use the common name instead. >> >> Signed-off-by: Dmitry Baryshkov >> --- >> Dmitry Baryshkov (3): >> wifi: ath10k: populate board data for WCN3990 >> wifi: ath10k: drop chip-specific board data file name >> wifi: ath10k: drop fw.eboard file name >> >> drivers/net/wireless/ath/ath10k/core.c | 32 >> - >> drivers/net/wireless/ath/ath10k/hw.h| 14 ++--- >> drivers/net/wireless/ath/ath10k/pci.c | 10 - >> drivers/net/wireless/ath/ath10k/targaddrs.h | 3 +++ >> 4 files changed, 14 insertions(+), 45 deletions(-) >> --- >> base-commit: 596764183be8ebb13352b281a442a1f1151c9b06 >> change-id: 20240129-wcn3990-board-fw-a2d97507a712 > > Kalle, Jeff, is there anything pending on me on this series? This is in my queue (Deferred state): https://patchwork.kernel.org/project/linux-wireless/list/?series=821157&state=*&order=date Unfortunately there is not really much time for ath10k nowadays so there will be delays. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [3/6] wifi: rsi: sdio: simplify module initialization
Krzysztof Kozlowski wrote: > This driver's initialization functions do not perform any custom code, > except printing messages. Printing messages on modules > loading/unloading is discouraged because it pollutes the dmesg > regardless whether user actually has this device. Core kernel code > already gives tools to investigate whether module was loaded or not. > > Drop the printing messages which allows to replace open-coded > module_sdio_driver(). > > Signed-off-by: Krzysztof Kozlowski 4 patches applied to wireless-next.git, thanks. 73ec84df3469 wifi: rsi: sdio: simplify module initialization 718fcb7d7b3f wifi: wl1251: simplify module initialization c33c93e9e96a wifi: wilc1000: replace open-coded module_sdio_driver() 170861bc0044 wifi: mwifiex: replace open-coded module_sdio_driver() -- https://patchwork.kernel.org/project/linux-wireless/patch/20240329171019.63836-3-krzysztof.kozlow...@linaro.org/ 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 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. -- 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
Dmitry Baryshkov writes: >> 3) ADD that compatible to the wifi node in msm8998.dtsi >>compatible = "qcom,wcn3990-wifi", "qcom,msm8998-wifi"; >> 4) In the driver, set qmi->fake_msa_ready_indicator to true if we >> detect "qcom,msm8998-wifi" >> >> And this approach would be acceptable to both ath10k & DT maintainers? > > 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 :/ -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RFC v2 0/4] wifi: ath10k: support board-specific firmware overrides
Jeff Johnson writes: > On 3/29/2024 9:47 PM, Dmitry Baryshkov wrote: > >> On Wed, 6 Mar 2024 at 10:16, Dmitry Baryshkov >> wrote: >>> >>> On WCN3990 platforms actual firmware, wlanmdsp.mbn, is sideloaded to the >>> modem DSP via the TQFTPserv. These MBN files are signed by the device >>> vendor, can only be used with the particular SoC or device. >>> >>> Unfortunately different firmware versions come with different features. >>> For example firmware for SDM845 doesn't use single-chan-info-per-channel >>> feature, while firmware for QRB2210 / QRB4210 requires that feature. >>> >>> Allow board DT files to override the subdir of the fw dir used to lookup >>> the firmware-N.bin file decribing corresponding WiFi firmware. >>> For example, adding firmware-name = "qrb4210" property will make the >>> driver look for the firmware-N.bin first in ath10k/WCN3990/hw1.0/qrb4210 >>> directory and then fallback to the default ath10k/WCN3990/hw1.0 dir. >>> >>> Signed-off-by: Dmitry Baryshkov >>> --- >>> Changes in v2: >>> - Fixed the comment about the default board name being NULL (Kalle) >>> - Expanded commit message to provide examples for firmware paths (Kalle) >>> - Added a note regarding board-2.bin to the commit message (Kalle) >>> - Link to v1: >>> https://lore.kernel.org/r/20240130-wcn3990-firmware-path-v1-0-826b93202...@linaro.org >>> >>> --- >>> Dmitry Baryshkov (4): >>> dt-bindings: net: wireless: ath10k: describe firmware-name property >>> wifi: ath10k: support board-specific firmware overrides >>> arm64: dts: qcom: qrb2210-rb1: add firmware-name qualifier to WiFi >>> node >>> arm64: dts: qcom: qrb4210-rb1: add firmware-name qualifier to WiFi >>> node >> >> Kalle, Jeff, is there anything pending on me on this series? >> > Nothing from me -- this is outside my area of expertise so I'm deferring to > Kalle. I was on Easter vacation and now catching up, that's why the delay. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/6] wifi: ath6kl: sdio: simplify module initialization
Krzysztof Kozlowski wrote: > This driver's initialization functions do not perform any custom code, > except printing messages. Printing messages on modules > loading/unloading is discouraged because it pollutes the dmesg > regardless whether user actually has this device. Core kernel code > already gives tools to investigate whether module was loaded or not. > > Drop the printing messages which allows to replace open-coded > module_sdio_driver(). > > Signed-off-by: Krzysztof Kozlowski > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 565759ce814a wifi: ath6kl: sdio: simplify module initialization -- https://patchwork.kernel.org/project/linux-wireless/patch/20240329171019.63836-2-krzysztof.kozlow...@linaro.org/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/6] wifi: ath10k: sdio: simplify module initialization
Krzysztof Kozlowski writes: > On 03/04/2024 15:50, Kalle Valo wrote: > >> Jeff Johnson writes: >> >>> On 3/29/2024 10:10 AM, Krzysztof Kozlowski wrote: >>>> This driver's initialization functions do not perform any custom code, >>>> except printing messages. Printing messages on modules >>>> loading/unloading is discouraged because it pollutes the dmesg >>>> regardless whether user actually has this device. Core kernel code >>>> already gives tools to investigate whether module was loaded or not. >>>> >>>> Drop the printing messages which allows to replace open-coded >>>> module_sdio_driver(). >>>> >>>> Signed-off-by: Krzysztof Kozlowski >>> >>> Acked-by: Jeff Johnson >>> >>>> >>>> --- >>>> >>>> FYI: >>>> I have ongoing patchset touching few lines above this patch chunk >>>> (sdio_driver) which might go via different tree. If that patchset is >>>> applied via different tree, it might result in a trivial conflict, but >>>> there is no dependency. They can go via separate trees (except that >>>> trivial conflict). >>> >>> I'll let Kalle respond if he'll take this through the ath tree vs letting >>> you >>> take it through your tree >> >> I prefer to avoid conflicts as much as possible. In this patchset I'm >> not anticipating any conflicts with wireless trees, so if we can avoid >> any conflicts, please take this patchset via the other tree: >> >> Acked-by: Kalle Valo >> >> I'll drop this patchset from my queue. But if I should take these to >> wireless trees instead just let me know. > > Just to clarify - only the first patch has possible conflict. The rest > should be fine. Ah, I was not quite sure what patches had the conflict. > Can you pick up 2-6 patches from this set? Yeah, that sounds the best. So patches 2-6 are back in my queue: https://patchwork.kernel.org/project/linux-wireless/list/?series=839844&state=*&order=date -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 7/7] wifi: silabs: wfx: drop driver owner initialization
Krzysztof Kozlowski writes: > Core in sdio_register_driver() already sets the .owner, so driver does > not need to. > > Signed-off-by: Krzysztof Kozlowski Also here the preferred title format is: wifi: wfx: drop driver owner initialization Feel free to take this via sdio tree: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 6/7] wifi: marvell: mwifiex: drop driver owner initialization
Krzysztof Kozlowski writes: > Core in sdio_register_driver() already sets the .owner, so driver does > not need to. > > Signed-off-by: Krzysztof Kozlowski The preferred title format is: wifi: mwifiex: drop driver owner initialization But that's just cosmetics. Feel free to take this via sdio tree: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/6] wifi: ath10k: sdio: simplify module initialization
Jeff Johnson writes: > On 3/29/2024 10:10 AM, Krzysztof Kozlowski wrote: >> This driver's initialization functions do not perform any custom code, >> except printing messages. Printing messages on modules >> loading/unloading is discouraged because it pollutes the dmesg >> regardless whether user actually has this device. Core kernel code >> already gives tools to investigate whether module was loaded or not. >> >> Drop the printing messages which allows to replace open-coded >> module_sdio_driver(). >> >> Signed-off-by: Krzysztof Kozlowski > > Acked-by: Jeff Johnson > >> >> --- >> >> FYI: >> I have ongoing patchset touching few lines above this patch chunk >> (sdio_driver) which might go via different tree. If that patchset is >> applied via different tree, it might result in a trivial conflict, but >> there is no dependency. They can go via separate trees (except that >> trivial conflict). > > I'll let Kalle respond if he'll take this through the ath tree vs letting you > take it through your tree I prefer to avoid conflicts as much as possible. In this patchset I'm not anticipating any conflicts with wireless trees, so if we can avoid any conflicts, please take this patchset via the other tree: Acked-by: Kalle Valo I'll drop this patchset from my queue. But if I should take these to wireless trees instead just let me know. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: pull-request: ath-next-20240402
Kalle Valo wrote: > Hi, > > Please pull, more information in the tag below. > > Kalle > > > The following changes since commit f654e228ed6b822e87e6e6ad8e889bedccae2e16: > > Merge tag 'ath-next-20240305' of > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath (2024-03-05 20:57:28 > +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git > tags/ath-next-20240402 > > for you to fetch changes up to f09e3b774fe806ee0b1f2bb69771e8c29961e40a: > > wifi: ath9k: eeprom: fix sparse endian warnings (2024-03-25 12:51:37 +0200) > > > ath.git patches for v6.10 > > ath drivers now have no remaining sparse warnings, otherwise smaller > fixes and some refactoring. > > ath11k > > * P2P support for QCA6390, WCN6855 and QCA2066 > > > Aloka Dixit (1): > wifi: ath12k: use correct flag field for 320 MHz channels > > Baochen Qiang (3): > wifi: ath10k: poll service ready message before failing > wifi: ath11k: don't force enable power save on non-running vdevs > wifi: ath11k: do not process consecutive RDDM event > > Jeff Johnson (3): > wifi: ath12k: remove obsolete struct wmi_start_scan_arg > wifi: ath11k: remove obsolete struct wmi_start_scan_arg > wifi: ath11k: fix soc_dp_stats debugfs file permission > > Kalle Valo (7): > wifi: ath6kl: fix sparse warnings > wifi: wcn36xx: buff_to_be(): fix sparse warnings > wifi: wcn36xx: main: fix sparse warnings > wifi: wil6210: fix sparse warnings > wifi: ath9k: ath9k_set_moredata(): fix sparse warnings > wifi: ath9k: fix ath9k_use_msi declaration > wifi: ath9k: eeprom: fix sparse endian warnings > > Kang Yang (8): > wifi: ath11k: change interface combination for P2P mode > wifi: ath11k: add P2P IE in beacon template > wifi: ath11k: implement handling of P2P NoA event > wifi: ath11k: change WLAN_SCAN_PARAMS_MAX_IE_LEN from 256 to 512 > wifi: ath11k: change scan flag scan_f_filter_prb_req for > QCA6390/WCN6855/QCA2066 > wifi: ath11k: advertise P2P dev support for QCA6390/WCN6855/QCA2066 > wifi: ath12k: remove duplicate definitions in wmi.h > wifi: ath11k: remove duplicate definitions in wmi.h > > Karthikeyan Periyasamy (3): > wifi: ath12k: Refactor Rxdma buffer replinish argument > wifi: ath12k: Optimize the lock contention of used list in Rx data path > wifi: ath12k: Refactor error handler of Rxdma replenish > > Kevin Lo (1): > wifi: ath11k: adjust a comment to reflect reality > > Li Zhijian (1): > wifi: ath: Convert sprintf/snprintf to sysfs_emit > > Thiraviyam Mariyappan (1): > wifi: ath12k: fix desc address calculation in wbm tx completion > > drivers/net/wireless/ath/ath10k/thermal.c| 2 +- > drivers/net/wireless/ath/ath10k/wmi.c| 26 +++- > drivers/net/wireless/ath/ath11k/Makefile | 3 +- > drivers/net/wireless/ath/ath11k/core.c | 20 ++- > drivers/net/wireless/ath/ath11k/debugfs.c| 4 +- > drivers/net/wireless/ath/ath11k/mac.c| 175 > +-- > drivers/net/wireless/ath/ath11k/mhi.c| 17 ++- > drivers/net/wireless/ath/ath11k/p2p.c| 149 +++ > drivers/net/wireless/ath/ath11k/p2p.h| 22 > drivers/net/wireless/ath/ath11k/pci.h| 1 + > drivers/net/wireless/ath/ath11k/thermal.c| 2 +- > drivers/net/wireless/ath/ath11k/wmi.c| 107 +++- > drivers/net/wireless/ath/ath11k/wmi.h| 78 ++-- > drivers/net/wireless/ath/ath12k/dp.c | 31 +++-- > drivers/net/wireless/ath/ath12k/dp.h | 7 +- > drivers/net/wireless/ath/ath12k/dp_rx.c | 140 + > drivers/net/wireless/ath/ath12k/dp_rx.h | 1 + > drivers/net/wireless/ath/ath12k/dp_tx.c | 2 +- > drivers/net/wireless/ath/ath12k/wmi.c| 2 +- > drivers/net/wireless/ath/ath12k/wmi.h| 34 -- > drivers/net/wireless/ath/ath6kl/htc_mbox.c | 3 +- > drivers/net/wireless/ath/ath6kl/htc_pipe.c | 3 +- > drivers/net/wireless/ath/ath9k/ath9k.h | 1 + > drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 +- > drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 +- > drivers/net/wireless/ath/ath9k/eeprom_def.c | 6 +- > drivers/net/wireless/ath/ath9k/pci.c | 2 - > drivers/net/wireless/ath/ath9k/xmit.c| 10 +- > drivers/net/wireless/ath/wcn36xx/main.c |
pull-request: ath-next-20240402
Hi, Please pull, more information in the tag below. Kalle The following changes since commit f654e228ed6b822e87e6e6ad8e889bedccae2e16: Merge tag 'ath-next-20240305' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath (2024-03-05 20:57:28 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git tags/ath-next-20240402 for you to fetch changes up to f09e3b774fe806ee0b1f2bb69771e8c29961e40a: wifi: ath9k: eeprom: fix sparse endian warnings (2024-03-25 12:51:37 +0200) ath.git patches for v6.10 ath drivers now have no remaining sparse warnings, otherwise smaller fixes and some refactoring. ath11k * P2P support for QCA6390, WCN6855 and QCA2066 Aloka Dixit (1): wifi: ath12k: use correct flag field for 320 MHz channels Baochen Qiang (3): wifi: ath10k: poll service ready message before failing wifi: ath11k: don't force enable power save on non-running vdevs wifi: ath11k: do not process consecutive RDDM event Jeff Johnson (3): wifi: ath12k: remove obsolete struct wmi_start_scan_arg wifi: ath11k: remove obsolete struct wmi_start_scan_arg wifi: ath11k: fix soc_dp_stats debugfs file permission Kalle Valo (7): wifi: ath6kl: fix sparse warnings wifi: wcn36xx: buff_to_be(): fix sparse warnings wifi: wcn36xx: main: fix sparse warnings wifi: wil6210: fix sparse warnings wifi: ath9k: ath9k_set_moredata(): fix sparse warnings wifi: ath9k: fix ath9k_use_msi declaration wifi: ath9k: eeprom: fix sparse endian warnings Kang Yang (8): wifi: ath11k: change interface combination for P2P mode wifi: ath11k: add P2P IE in beacon template wifi: ath11k: implement handling of P2P NoA event wifi: ath11k: change WLAN_SCAN_PARAMS_MAX_IE_LEN from 256 to 512 wifi: ath11k: change scan flag scan_f_filter_prb_req for QCA6390/WCN6855/QCA2066 wifi: ath11k: advertise P2P dev support for QCA6390/WCN6855/QCA2066 wifi: ath12k: remove duplicate definitions in wmi.h wifi: ath11k: remove duplicate definitions in wmi.h Karthikeyan Periyasamy (3): wifi: ath12k: Refactor Rxdma buffer replinish argument wifi: ath12k: Optimize the lock contention of used list in Rx data path wifi: ath12k: Refactor error handler of Rxdma replenish Kevin Lo (1): wifi: ath11k: adjust a comment to reflect reality Li Zhijian (1): wifi: ath: Convert sprintf/snprintf to sysfs_emit Thiraviyam Mariyappan (1): wifi: ath12k: fix desc address calculation in wbm tx completion drivers/net/wireless/ath/ath10k/thermal.c| 2 +- drivers/net/wireless/ath/ath10k/wmi.c| 26 +++- drivers/net/wireless/ath/ath11k/Makefile | 3 +- drivers/net/wireless/ath/ath11k/core.c | 20 ++- drivers/net/wireless/ath/ath11k/debugfs.c| 4 +- drivers/net/wireless/ath/ath11k/mac.c| 175 +-- drivers/net/wireless/ath/ath11k/mhi.c| 17 ++- drivers/net/wireless/ath/ath11k/p2p.c| 149 +++ drivers/net/wireless/ath/ath11k/p2p.h| 22 drivers/net/wireless/ath/ath11k/pci.h| 1 + drivers/net/wireless/ath/ath11k/thermal.c| 2 +- drivers/net/wireless/ath/ath11k/wmi.c| 107 +++- drivers/net/wireless/ath/ath11k/wmi.h| 78 ++-- drivers/net/wireless/ath/ath12k/dp.c | 31 +++-- drivers/net/wireless/ath/ath12k/dp.h | 7 +- drivers/net/wireless/ath/ath12k/dp_rx.c | 140 + drivers/net/wireless/ath/ath12k/dp_rx.h | 1 + drivers/net/wireless/ath/ath12k/dp_tx.c | 2 +- drivers/net/wireless/ath/ath12k/wmi.c| 2 +- drivers/net/wireless/ath/ath12k/wmi.h| 34 -- drivers/net/wireless/ath/ath6kl/htc_mbox.c | 3 +- drivers/net/wireless/ath/ath6kl/htc_pipe.c | 3 +- drivers/net/wireless/ath/ath9k/ath9k.h | 1 + drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 +- drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 +- drivers/net/wireless/ath/ath9k/eeprom_def.c | 6 +- drivers/net/wireless/ath/ath9k/pci.c | 2 - drivers/net/wireless/ath/ath9k/xmit.c| 10 +- drivers/net/wireless/ath/wcn36xx/main.c | 4 +- drivers/net/wireless/ath/wcn36xx/txrx.c | 4 +- drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 7 +- drivers/net/wireless/ath/wil6210/cfg80211.c | 4 +- drivers/net/wireless/ath/wil6210/fw.h| 1 - drivers/net/wireless/ath/wil6210/fw_inc.c| 4 +- 34 files changed, 660 insertions(+), 218 deletions(-) create mode 100644 drivers/net/wireless/ath/ath11k/p2p.c create mode 100644 drivers/net/wireless/ath/ath11k/p2p.h
Re: [PATCH] ath10k: allocate dummy net_device dynamically
Jakub Kicinski writes: > On Fri, 22 Mar 2024 07:58:02 -0700 Breno Leitao wrote: >> > Looks like init_dummy_netdev wipes the netdev structure clean, so I >> > don't think we can use it directly as the setup function, Breno :( >> >> Before my patch, init_dummy_netdev was being also used. The patch was >> basically replacing the init_dummy_netdev by alloc_netdev() with will >> call "setup(dev);" later. >> >> - init_dummy_netdev(&irq_grp->napi_ndev); >> + irq_grp->napi_ndev = alloc_netdev(0, "dummy", >> NET_NAME_UNKNOWN, >> + init_dummy_netdev); >> >> I am wondering if alloc_netdev() is messing with something instead of >> init_dummy_netdev(). > > alloc_netdev() allocates some memory and initializes lists which > free_netdev() wants to free, basically. But init_dummy_netdev() does: > > /* Clear everything. Note we don't initialize spinlocks >* are they aren't supposed to be taken by any of the >* NAPI code and this dummy netdev is supposed to be >* only ever used for NAPI polls >*/ > memset(dev, 0, sizeof(struct net_device)); > > so all those pointers and init alloc_netdev() did before calling setup > will get wiped. After some tweaking I was able to get an old x86 laptop with ath10k back alive and I tested this patch using QCA9984/QCA9994 hw1.0 PCI device. As expected it did crash during rmmod and it seems to crash because dev->dev_addr is zero: [ 130.849286] dev->dev_addr dev->dev_addr_shadow 5acebe41 Breno, I can now easily test new ath10k and ath11k patches, just let me know. Here's the full back trace: [ 130.849310] BUG: kernel NULL pointer dereference, address: [ 130.849413] #PF: supervisor read access in kernel mode [ 130.849450] #PF: error_code(0x) - not-present page [ 130.849486] *pdpt = 048b9001 *pde = [ 130.849529] Oops: [#1] PREEMPT SMP PTI [ 130.849564] CPU: 1 PID: 882 Comm: rmmod Tainted: GE 6.9.0-rc1-wt-ath+ #17 [ 130.849617] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010 [ 130.849671] EIP: memcmp+0x4c/0x54 [ 130.849706] Code: 39 d9 74 0a 0f b6 03 0f b6 32 29 f0 74 ec 5b 5e 5d c3 8d b4 26 00 00 00 00 90 83 e9 04 83 c3 04 83 c2 04 83 f9 03 76 c2 8b 02 <39> 03 74 ec eb c0 66 90 55 89 e5 e8 a4 ff ff ff 5d c3 66 90 55 89 [ 130.849809] EAX: EBX: ECX: 0020 EDX: c32c1d84 [ 130.854170] ESI: c32c1d84 EDI: EBP: c4b87e2c ESP: c4b87e24 [ 130.854222] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010216 [ 130.854274] CR0: 80050033 CR2: CR3: 03348000 CR4: 06f0 [ 130.854324] Call Trace: [ 130.854354] ? show_regs+0x74/0x7c [ 130.854393] ? __die+0x1d/0x58 [ 130.854425] ? page_fault_oops+0x16c/0x340 [ 130.854469] ? kernelmode_fixup_or_oops.constprop.0+0x84/0xd4 [ 130.854518] ? __bad_area_nosemaphore.constprop.0+0x10e/0x1a4 [ 130.854567] ? lock_mm_and_find_vma+0xeb/0x288 [ 130.854612] ? bad_area_nosemaphore+0xf/0x14 [ 130.854652] ? do_user_addr_fault+0x238/0x454 [ 130.854693] ? exc_page_fault+0x58/0x170 [ 130.854734] ? pvclock_clocksource_read_nowd+0x130/0x130 [ 130.854781] ? handle_exception+0x150/0x150 [ 130.854824] ? posix_cpu_timer_del+0x17/0x140 [ 130.854867] ? pvclock_clocksource_read_nowd+0x130/0x130 [ 130.854914] ? memcmp+0x4c/0x54 [ 130.854947] ? pvclock_clocksource_read_nowd+0x130/0x130 [ 130.857510] ? memcmp+0x4c/0x54 [ 130.860078] dev_addr_check+0x27/0xd4 [ 130.862635] dev_addr_flush+0x18/0x78 [ 130.865178] free_netdev+0x76/0x1b0 [ 130.867708] ath10k_core_destroy+0x54/0x84 [ath10k_core] [ 130.870283] ath10k_pci_remove+0x88/0xcc [ath10k_pci] [ 130.872831] pci_device_remove+0x38/0x90 [ 130.875311] device_remove+0x37/0x58 [ 130.877757] device_release_driver_internal+0x185/0x1d8 [ 130.880182] driver_detach+0x3c/0x78 [ 130.882603] bus_remove_driver+0x56/0xc0 [ 130.885019] driver_unregister+0x25/0x40 [ 130.887378] pci_unregister_driver+0x21/0x60 [ 130.889702] ath10k_pci_exit+0xd/0x3d0 [ath10k_pci] [ 130.892007] __ia32_sys_delete_module+0x163/0x254 [ 130.894291] ? preempt_count_add+0x6d/0xbc [ 130.896504] ? debug_smp_processor_id+0x12/0x14 [ 130.898711] ? fpregs_assert_state_consistent+0x29/0x50 [ 130.900883] __do_fast_syscall_32+0x57/0xd0 [ 130.903026] do_fast_syscall_32+0x29/0x58 [ 130.905178] do_SYSENTER_32+0x15/0x18 [ 130.907295] entry_SYSENTER_32+0xa2/0x102 [ 130.909421] EIP: 0xb7ef0569 [ 130.911523] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76 [ 130.916271] EAX: ffda EBX: 010f618c ECX: 0800 EDX: 0044b1f9 [ 130.918758] ESI: 010f6150 EDI: 0001 EBP: bf8957f3 ESP: bf8941b8 [ 130.921221] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 0202 [ 130.9
Re: [PATCH v2 1/3] wifi: ath: Convert sprintf/snprintf to sysfs_emit
Li Zhijian wrote: > Per filesystems/sysfs.rst, show() should only use sysfs_emit() > or sysfs_emit_at() when formatting the value to be returned to user space. > > coccinelle complains that there are still a couple of functions that use > snprintf(). Convert them to sysfs_emit(). > > sprintf() will be converted as weel if they have. > > Generally, this patch is generated by > make coccicheck M= MODE=patch \ > COCCI=scripts/coccinelle/api/device_attr_show.cocci > > No functional change intended > > CC: Kalle Valo > CC: Jeff Johnson > CC: linux-wirel...@vger.kernel.org > CC: ath...@lists.infradead.org > CC: ath10k@lists.infradead.org > Signed-off-by: Li Zhijian > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. fa1a4f15bdca wifi: ath: Convert sprintf/snprintf to sysfs_emit -- https://patchwork.kernel.org/project/linux-wireless/patch/20240315055211.1347548-1-lizhij...@fujitsu.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ath10k: allocate dummy net_device dynamically
Jeff Johnson writes: > On 3/19/2024 3:47 AM, Breno Leitao wrote: >> Embedding net_device into structures prohibits the usage of flexible >> arrays in the net_device structure. For more details, see the discussion >> at [1]. >> >> Un-embed the net_device from struct ath10k by converting it >> into a pointer. Then use the leverage alloc_netdev() to allocate the >> net_device object at ath10k_core_create(). The free of the device occurs >> at ath10k_core_destroy(). >> >> [1] https://lore.kernel.org/all/20240229225910.79e22...@kernel.org/ >> >> Signed-off-by: Breno Leitao > > NAK this based upon the ath11k patch results. > > As suggested there we should just use kmalloc/kfree to match the existing > logic. BTW if the patch is not tested on a real device then it's good to document that in the commit message with "Compile tested only" or similar. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: QCA6174 showing terrible performance when connecting via WPA3-SAE
Eric Park writes: > Hello! I have a Samsung NT500R5H-Y53L with the QCA6174 card, and I > noticed I was getting terrible performance (around 20-30 Mbps) > compared to other devices on the network (600-700 Mbps), when running > a speedtest. > > I tried modifying some settings and discovered that I can get around > 500-600 Mbps on the speedtest if I limited the router settings to > WPA2-PSK, but once I set the setting to allow for both WPA2 and WPA3, > the card connects using WPA3-SAE but then has terrible performance as > a result. > > Is this a driver bug, or a limitation of the hardware? My first guess it's because of software encryption with these cipher suites (from ath10k_set_key()): /* this one needs to be done in software */ if (key->cipher == WLAN_CIPHER_SUITE_AES_CMAC || key->cipher == WLAN_CIPHER_SUITE_BIP_GMAC_128 || key->cipher == WLAN_CIPHER_SUITE_BIP_GMAC_256 || key->cipher == WLAN_CIPHER_SUITE_BIP_CMAC_256) return 1; 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. > Is there a way to force the card to connect over WPA2-PSK? That's a user space decision and depends on what connection manager you use. For example, here's some info how to setup key management with Network Manager: https://askubuntu.com/questions/1290589/how-to-use-wpa3-with-ubuntu-20-04 -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH RFC v2 0/4] wifi: ath10k: support board-specific firmware overrides
Dmitry Baryshkov writes: >> To be on the safe side using 'qcom-rb1' makes sense but on the other >> hand that means we need to update linux-firmware (basically add a new >> symlink) everytime a new product is added. But are there going to be >> that many new ath10k based products? >> >> Using 'qcm2290' is easier because for a new product then there only >> needs to be a change in DTS and no need to change anything >> linux-firmware. But here the risk is that if there's actually two >> different ath10k firmware branches for 'qcm2290'. If that ever happens >> (I hope not) I guess we could solve that by adding new 'qcm2290-foo' >> directory? >> >> But I don't really know, thoughts? > > After some thought, I'd suggest to follow approach taken by the rest > of qcom firmware: Can you provide pointers to those cases? > put a default (accepted by non-secured hardware) firmware to SoC dir > and then put a vendor-specific firmware into subdir. If any of such > vendors appear, we might even implement structural fallback: first > look into sdm845/Google/blueline, then in sdm845/Google, sdm845/ and > finally just under hw1.0. Honestly that looks quite compilicated compared to having just one sub-directory. How will ath10k find the directory names (or I vendor and model names) like 'Google' or 'blueline' in this example? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] wifi: ath10k: poll service ready message before failing
Baochen Qiang wrote:
> Currently host relies on CE interrupts to get notified that
> the service ready message is ready. This results in timeout
> issue if the interrupt is not fired, due to some unknown
> reasons. See below logs:
>
> [76321.937866] ath10k_pci :02:00.0: wmi service ready event not received
> ...
> [76322.016738] ath10k_pci :02:00.0: Could not init core: -110
>
> And finally it causes WLAN interface bring up failure.
>
> Change to give it one more chance here by polling CE rings,
> before failing directly.
>
> Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00157-QCARMSWPZ-1
>
> Fixes: 5e3dd157d7e7 ("ath10k: mac80211 driver for Qualcomm Atheros 802.11ac
> CQA98xx devices")
> Reported-by: James Prestwood
> Tested-By: James Prestwood # on QCA6174 hw3.2
> Link:
> https://lore.kernel.org/linux-wireless/304ce305-fbe6-420e-ac2a-d61ae5e6c...@gmail.com/
> Signed-off-by: Baochen Qiang
> Acked-by: Jeff Johnson
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
e57b7d62a1b2 wifi: ath10k: poll service ready message before failing
--
https://patchwork.kernel.org/project/linux-wireless/patch/20240227030409.89702-1-quic_bqi...@quicinc.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
