- 12 Apr, 2023 1 commit
-
-
Manikanta Pubbisetty authored
Currently, time taken to scan all supported channels on WCN6750 is ~8 seconds and connection time is almost 10 seconds. WCN6750 supports three Wi-Fi bands (i.e., 2.4/5/6 GHz) and the numbers of channels for scan come around ~100 channels (default case). Since the chip doesn't have support for DBS (Dual Band Simultaneous), scans cannot be parallelized resulting in longer scan times. Among the 100 odd channels, ~60 channels are in 6 GHz band. Therefore, optimizing the scan for 6 GHz channels will bring down the overall scan time. WCN6750 firmware has support to scan a 6 GHz channel based on co-located AP information i.e., RNR IE which is found in the legacy 2.4/5 GHz scan results. When a scan request with all supported channel list is enqueued to the firmware, then based on WMI_SCAN_CHAN_FLAG_SCAN_ONLY_IF_RNR_FOUND scan channel flag, firmware will scan only those 6 GHz channels for which RNR IEs are found in the legacy scan results. In the proposed design, based on NL80211_SCAN_FLAG_COLOCATED_6GHZ scan flag, driver will set the WMI_SCAN_CHAN_FLAG_SCAN_ONLY_IF_RNR_FOUND flag for non-PSC channels. Since there is high probability to find 6 GHz APs on PSC channels, these channels are always scanned. Only non-PSC channels are selectively scanned based on cached RNR information from the legacy scan results. If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set in the scan flags, then scan will happen on all supported channels (default behavior). With these optimizations, scan time is improved by 1.5-1.8 seconds on WCN6750. Similar savings have been observed on WCN6855. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16 Signed-off-by:
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230323060913.10097-1-quic_mpubbise@quicinc.com
-
- 24 Mar, 2023 8 commits
-
-
Gustavo A. R. Silva authored
Zero-length arrays as fake flexible arrays are deprecated and we are moving towards adopting C99 flexible-array members instead. Address the following warnings found with GCC-13 and -fstrict-flex-arrays=3 enabled: drivers/net/wireless/ath/carl9170/tx.c:702:61: warning: array subscript i is outside array bounds of ‘const struct _carl9170_tx_status[0]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/tx.c:701:65: warning: array subscript i is outside array bounds of ‘const struct _carl9170_tx_status[0]’ [-Warray-bounds=] This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/21 Link: https://github.com/KSPP/linux/issues/267 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by:
Christian Lamparter <chunkeey@gmail.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Gustavo A. R. Silva authored
GCC (and Clang)[1] does not like having a partially allocated object, since it cannot reason about it for bounds checking. Instead, fully allocate struct carl9170_cmd. Fix the following warnings Seen under GCC 13: drivers/net/wireless/ath/carl9170/cmd.c:125:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[4]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:126:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[4]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:125:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[20]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:126:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[20]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:161:12: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[20]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:162:12: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[20]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:163:12: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[20]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:164:12: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[20]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:125:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[8]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:126:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[8]’ [-Warray-bounds=] drivers/net/wireless/ath/carl9170/cmd.c:220:12: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[8]’ [-Warray-bounds=] Link: https://github.com/KSPP/linux/issues/268 Link: godbolt.org/z/KP97sxh3T [1] Signed-off-by:
-
Tom Rix authored
clang with W=1 reports: drivers/net/wireless/ath/ath10k/ce.c:88:1: error: unused function 'ath10k_get_ring_byte' [-Werror,-Wunused-function] ath10k_get_ring_byte(unsigned int offset, ^ This function is not used so remove it. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Johan Hovold authored
Add devicetree bindings for Qualcomm ath11k PCIe devices such as WCN6855 for which the calibration data variant may need to be described. Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Harshitha Prem authored
When underlying hardware supports more than one band, then wiphy is aware of all the frequency bands present. Example, say wiphy0 is aware of 2 GHz, 5 GHz and 6 GHz band information. Hence, when an virtual AP interface is brought up in auto channel selection on each band. Survey is initiated from the userspace application for all the virtual AP interfaces simultaneously. For survey dump collection, freq_to_idx() api is used to map the index of particular frequency to populate its survey. When the dump was collected, the index fetched was incorrect. Example, in case of multi-hardware, the index of channel 36 was reported as 14, because wiphy0 had index 0-13 for 2 GHz channels, instead of 0 for that ar which resulted in invalid survey sent to userspace application. The incorrect index was because of the mapping did not consider whether the freq band is present in its radio structure (ar) or not. To handle this, the freq_to_idx() api should map index for the particular band in the ar structure. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by:
-
Harshitha Prem authored
When a data traffic with size greater than 1500 is initiated, say size 65500, it is sent as a set of AMSDUs (3 MSDUs) in a MPDU. These AMSDUs are incorrectly classified as multicast and peer id gets changed, except for first msdu, because of mcast_bcast bit derived from rx_desc for every msdu received. The mcast_bcast bit in rx_desc is only valid for first msdu. Hence, add changes to derive mcast_bcast only if it is a first msdu. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Aaradhana Sahu authored
Currently, if we set raw mode as encap type, packets are sent in native wifi mode which is default mode. This is caused by no check being present for raw mode in ath12k_dp_tx_get_encap_type function, so it's always going in native wifi mode. Fix, this issue by adding check condition for raw mode. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Aaradhana Sahu <quic_aarasahu@quicinc.com> Signed-off-by:
-
P Praneesh authored
Firmware expects physical address in the reo entrance ring when MLO is enabled and peer meta data in the queue_addr_lo for the non MLO cases. Current implementation fills the physical address for the non MLO cases and firmware decodes it differently which leads to SOC CSR region access which is not related to firmware/MAC operation. Fix this by sending only peer_meta data and destination indication bit during non MLO case. This prevents firmware from invalid decoding. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
P Praneesh <quic_ppranees@quicinc.com> Signed-off-by:
Manish Dharanenthiran <quic_mdharane@quicinc.com> Signed-off-by:
-
- 22 Mar, 2023 5 commits
-
-
Baochen Qiang authored
To reduce power consumption, change idle_ps to true to enable Idle Mode Power Save (IMPS) for WCN7850. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Signed-off-by:
Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by:
-
Baochen Qiang authored
WMI_CHAN_INFO_DFS flag should be set when configuring a DFS channel included in scan channel list. Without it, firmware will not send a probe request frame which is needed in connection to an AP configured with hidden SSID/network_id. So fix this to allow probe request frames to be sent in cases where a beacon frame has been seen on the channel first. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Signed-off-by:
-
Aditya Kumar Singh authored
Currently, during change in bandwidth for peer sta, host sends the new value of channel width via WMI_PEER_CHWIDTH set peer param command alone. This can lead to firmware assert in some scenario since before the command, firmware was having value of channel width and its corresponding phymode. After the command, host tries to set the new value of channel width alone which can become incompatible when compared with its phymode. For example: Bandwidth Upgrade ~~~~~~~~~~~~~~~~~~ After association, sta is in 40 MHz bandwidth in 11ax-HE40 phymode. After bandwidth upgrades, sta moves to 80 MHz but as per phymode, max bandwidth is still 40 MHz. Hence, firmware assert is seen. So in this case first phymode should be moved to 11ax-HE80 followed by bandwidth change. Bandwidth Downgrade ~~~~~~~~~~~~~~~~~~ Similarly, reverse of above is also possible when sta is in 40 MHz bandwidth in 11ax-HE40 phymode. Bandwidth should be changed to 20 MHz and if host sends phymode first then, phymode will become 11ax-HE20 and will be incompatible with bandwidth value and hence firmware assert will be seen. Hence, in this case first channel width should be set followed by phymode. Fix this issue by sending WMI set peer param command for phymode as well as bandwidth based on the type of bandwidth change i.e upgrade or downgrade. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Aditya Kumar Singh <quic_adisi@quicinc.com> Signed-off-by:
-
Rajat Soni authored
Currently the buffer pointed by event is not freed in case ATH12K_FLAG_UNREGISTERING bit is set, this causes memory leak. Add a goto skip instead of return, to ensure event and all the list entries are freed properly. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Rajat Soni <quic_rajson@quicinc.com> Signed-off-by:
-
Harshitha Prem authored
Perform dma_sync_single_for_cpu() on monitor ring rx buffer before reading BUFFER_DONE tag and do dma_unmap_single() only after device had set BUFFER_DONE tag to the buffer. Also when BUFFER_DONE tag is not set, allow the buffer to get read next time without freeing skb. This helps to fix AP+Monitor VAP with flood traffic scenario to see monitor ring rx buffer overrun missing BUFFER_DONE tag to be set. Also remove redundant rx dma buf free performed on DP rx_mon_status_refill_ring. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Sathishkumar Muruganandam <quic_murugana@quicinc.com> Signed-off-by:
-
- 15 Mar, 2023 5 commits
-
-
Aditya Kumar Singh authored
Currently, in ath11k_ahb_fw_resources_init(), iommu domain mapping is done only for the chipsets having fixed firmware memory. Also, for such chipsets, mapping is done only if it does not have TrustZone support. During deinitialization, only if TrustZone support is not there, iommu is unmapped back. However, for non fixed firmware memory chipsets, TrustZone support is not there and this makes the condition check to true and it tries to unmap the memory which was not mapped during initialization. This leads to the following trace - [ 83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 83.259537] Modules linked in: ath11k_ahb ath11k qmi_helpers .. snip .. [ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 83.287228] pc : __iommu_unmap+0x30/0x140 [ 83.293907] lr : iommu_unmap+0x5c/0xa4 [ 83.298072] sp : ffff80000b3abad0 .. snip .. [ 83.369175] Call trace: [ 83.376282] __iommu_unmap+0x30/0x140 [ 83.378541] iommu_unmap+0x5c/0xa4 [ 83.382360] ath11k_ahb_fw_resource_deinit.part.12+0x2c/0xac [ath11k_ahb] [ 83.385666] ath11k_ahb_free_resources+0x140/0x17c [ath11k_ahb] [ 83.392521] ath11k_ahb_shutdown+0x34/0x40 [ath11k_ahb] [ 83.398248] platform_shutdown+0x20/0x2c [ 83.403455] device_shutdown+0x16c/0x1c4 [ 83.407621] kernel_restart_prepare+0x34/0x3c [ 83.411529] kernel_restart+0x14/0x74 [ 83.415781] __do_sys_reboot+0x1c4/0x22c [ 83.419427] __arm64_sys_reboot+0x1c/0x24 [ 83.423420] invoke_syscall+0x44/0xfc [ 83.427326] el0_svc_common.constprop.3+0xac/0xe8 [ 83.430974] do_el0_svc+0xa0/0xa8 [ 83.435659] el0_svc+0x1c/0x44 [ 83.438957] el0t_64_sync_handler+0x60/0x144 [ 83.441910] el0t_64_sync+0x15c/0x160 [ 83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0) [ 83.449903] ---[ end trace 0000000000000000 ]--- This can be reproduced by probing an AHB chipset which is not having a fixed memory region. During reboot (or rmmod) trace can be seen. Fix this issue by adding a condition check on firmware fixed memory hw_param as done in the counter initialization function. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Fixes: f9eec494 ("ath11k: Add support for targets without trustzone") Signed-off-by:
-
Gustavo A. R. Silva authored
Zero-length arrays as fake flexible arrays are deprecated and we are moving towards adopting C99 flexible-array members instead. Address 25 of the following warnings found with GCC-13 and -fstrict-flex-arrays=3 enabled: drivers/net/wireless/ath/ath11k/debugfs_htt_stats.c:30:51: warning: array subscript <unknown> is outside array bounds of ‘const u32[0]’ {aka ‘const unsigned int[]’} [-Warray-bounds=] This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/21 Link: https://github.com/KSPP/linux/issues/266 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by:Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Harshit Mogalapalli authored
Smatch Warns: drivers/net/wireless/ath/ath12k/pci.c:1198 ath12k_pci_probe() warn: missing unwind goto? Store the error value in ret and use correct label with a goto. Only Compile tested, found with Smatch. Fixes: d8899132 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Reported-by:
Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/all/Y+426q6cfkEdb5Bv@kili/Suggested-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by:
-
Vladimir Lypak authored
Pronto v3 has a different DXE address than prior Pronto versions. This patch changes the macro to return the correct register address based on the pronto version. Signed-off-by:
Vladimir Lypak <vladimir.lypak@gmail.com> Signed-off-by:
Sireesh Kodali <sireeshkodali1@gmail.com> Signed-off-by:
-
Bastian Germann authored
The USB device 1668:1200 is Qwest/Actiontec 802AIN which is also correctly claimed to be supported by carl9170. Supposedly, the successor 802AIN2 has an ath9k compatible chip whose USB ID (unknown) could be inserted instead. Drop the ID from the wrong driver. I happened to find this by chance while packaging the ath9k and carl9170 firmware for Debian. Signed-off-by:
Bastian Germann <bage@debian.org> Acked-by:
Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by:
-
- 13 Mar, 2023 21 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v6.4. Major changes: ath10k * enable threaded napi on WCN3990 ath11k * push MU-MIMO params from hostapd to hardware * tx ack signal support for management packets
-
Jisoo Jang authored
Fix a slab-out-of-bounds read that occurs in kmemdup() called from brcmf_get_assoc_ies(). The bug could occur when assoc_info->req_len, data from a URB provided by a USB device, is bigger than the size of buffer which is defined as WL_EXTRA_BUF_MAX. Add the size check for req_len/resp_len of assoc_info. Found by a modified version of syzkaller. [ 46.592467][ T7] ================================================================== [ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50 [ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7 [ 46.598575][ T7] [ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145 [ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker [ 46.605943][ T7] Call Trace: [ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1 [ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334 [ 46.608610][ T7] ? kmemdup+0x3e/0x50 [ 46.609341][ T7] kasan_report.cold+0x79/0xd5 [ 46.610151][ T7] ? kmemdup+0x3e/0x50 [ 46.610796][ T7] kasan_check_range+0x14e/0x1b0 [ 46.611691][ T7] memcpy+0x20/0x60 [ 46.612323][ T7] kmemdup+0x3e/0x50 [ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60 [ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0 [ 46.614831][ T7] ? lock_chain_count+0x20/0x20 [ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770 [ 46.616552][ T7] ? lock_chain_count+0x20/0x20 [ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770 [ 46.618244][ T7] ? lock_chain_count+0x20/0x20 [ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0 [ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0 [ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790 [ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950 [ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 [ 46.623390][ T7] ? find_held_lock+0x2d/0x110 [ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60 [ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0 [ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0 [ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 [ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100 [ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60 [ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100 [ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 46.630649][ T7] process_one_work+0x92b/0x1460 [ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330 [ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90 [ 46.632347][ T7] worker_thread+0x95/0xe00 [ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0 [ 46.633393][ T7] ? process_one_work+0x1460/0x1460 [ 46.633957][ T7] kthread+0x3a1/0x480 [ 46.634369][ T7] ? set_kthread_struct+0x120/0x120 [ 46.634933][ T7] ret_from_fork+0x1f/0x30 [ 46.635431][ T7] [ 46.635687][ T7] Allocated by task 7: [ 46.636151][ T7] kasan_save_stack+0x1b/0x40 [ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90 [ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330 [ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040 [ 46.638275][ T7] brcmf_attach+0x389/0xd40 [ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690 [ 46.639279][ T7] usb_probe_interface+0x2aa/0x760 [ 46.639820][ T7] really_probe+0x205/0xb70 [ 46.640342][ T7] __driver_probe_device+0x311/0x4b0 [ 46.640876][ T7] driver_probe_device+0x4e/0x150 [ 46.641445][ T7] __device_attach_driver+0x1cc/0x2a0 [ 46.642000][ T7] bus_for_each_drv+0x156/0x1d0 [ 46.642543][ T7] __device_attach+0x23f/0x3a0 [ 46.643065][ T7] bus_probe_device+0x1da/0x290 [ 46.643644][ T7] device_add+0xb7b/0x1eb0 [ 46.644130][ T7] usb_set_configuration+0xf59/0x16f0 [ 46.644720][ T7] usb_generic_driver_probe+0x82/0xa0 [ 46.645295][ T7] usb_probe_device+0xbb/0x250 [ 46.645786][ T7] really_probe+0x205/0xb70 [ 46.646258][ T7] __driver_probe_device+0x311/0x4b0 [ 46.646804][ T7] driver_probe_device+0x4e/0x150 [ 46.647387][ T7] __device_attach_driver+0x1cc/0x2a0 [ 46.647926][ T7] bus_for_each_drv+0x156/0x1d0 [ 46.648454][ T7] __device_attach+0x23f/0x3a0 [ 46.648939][ T7] bus_probe_device+0x1da/0x290 [ 46.649478][ T7] device_add+0xb7b/0x1eb0 [ 46.649936][ T7] usb_new_device.cold+0x49c/0x1029 [ 46.650526][ T7] hub_event+0x1c98/0x3950 [ 46.650975][ T7] process_one_work+0x92b/0x1460 [ 46.651535][ T7] worker_thread+0x95/0xe00 [ 46.651991][ T7] kthread+0x3a1/0x480 [ 46.652413][ T7] ret_from_fork+0x1f/0x30 [ 46.652885][ T7] [ 46.653131][ T7] The buggy address belongs to the object at ffff888019442000 [ 46.653131][ T7] which belongs to the cache kmalloc-2k of size 2048 [ 46.654669][ T7] The buggy address is located 0 bytes inside of [ 46.654669][ T7] 2048-byte region [ffff888019442000, ffff888019442800) [ 46.656137][ T7] The buggy address belongs to the page: [ 46.656720][ T7] page:ffffea0000651000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x19440 [ 46.657792][ T7] head:ffffea0000651000 order:3 compound_mapcount:0 compound_pincount:0 [ 46.658673][ T7] flags: 0x100000000010200(slab|head|node=0|zone=1) [ 46.659422][ T7] raw: 0100000000010200 0000000000000000 dead000000000122 ffff888100042000 [ 46.660363][ T7] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 [ 46.661236][ T7] page dumped because: kasan: bad access detected [ 46.661956][ T7] page_owner tracks the page as allocated [ 46.662588][ T7] page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 7, ts 31136961085, free_ts 0 [ 46.664271][ T7] prep_new_page+0x1aa/0x240 [ 46.664763][ T7] get_page_from_freelist+0x159a/0x27c0 [ 46.665340][ T7] __alloc_pages+0x2da/0x6a0 [ 46.665847][ T7] alloc_pages+0xec/0x1e0 [ 46.666308][ T7] allocate_slab+0x380/0x4e0 [ 46.666770][ T7] ___slab_alloc+0x5bc/0x940 [ 46.667264][ T7] __slab_alloc+0x6d/0x80 [ 46.667712][ T7] kmem_cache_alloc_trace+0x30a/0x330 [ 46.668299][ T7] brcmf_usbdev_qinit.constprop.0+0x50/0x470 [ 46.668885][ T7] brcmf_usb_probe+0xc97/0x1690 [ 46.669438][ T7] usb_probe_interface+0x2aa/0x760 [ 46.669988][ T7] really_probe+0x205/0xb70 [ 46.670487][ T7] __driver_probe_device+0x311/0x4b0 [ 46.671031][ T7] driver_probe_device+0x4e/0x150 [ 46.671604][ T7] __device_attach_driver+0x1cc/0x2a0 [ 46.672192][ T7] bus_for_each_drv+0x156/0x1d0 [ 46.672739][ T7] page_owner free stack trace missing [ 46.673335][ T7] [ 46.673620][ T7] Memory state around the buggy address: [ 46.674213][ T7] ffff888019442700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 46.675083][ T7] ffff888019442780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 46.675994][ T7] >ffff888019442800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 46.676875][ T7] ^ [ 46.677323][ T7] ffff888019442880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 46.678190][ T7] ffff888019442900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 46.679052][ T7] ================================================================== [ 46.679945][ T7] Disabling lock debugging due to kernel taint [ 46.680725][ T7] Kernel panic - not syncing: Reviewed-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Jisoo Jang <jisoo.jang@yonsei.ac.kr> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230309104457.22628-1-jisoo.jang@yonsei.ac.kr
-
Dongliang Mu authored
drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe() warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811 Fix this by modifying return to a goto statement. Signed-off-by:
Dongliang Mu <dzm91@hust.edu.cn> Reviewed-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
To support v5 version firmware cycle report, apply the related structure and functions. v5 cycle report add a group of status to show how the free-run/TDMA training goes to. It is a firmware mechanism that can auto adjust coexistence mode between TDMA and free run mechanism at 3 antenna solution. v5 version provide more reference data to let the mechanism make decision. Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
Compare to v1 and v2 removed some not usable parameters. Save firmware code size. The information can show how frequent and how long the Bluetooth scan do. It will help to debug coexistence issue. Signed-off-by:
-
Ching-Te Ku authored
Correct pointer assignment of v1 null data report. It doesn't really change logic at all, but it looks more readable. Signed-off-by:
-
Ching-Te Ku authored
The v2 firmware report reduce its maximum register numbers from 30 to 20, it can help to save firmware code size. Signed-off-by:
-
Ching-Te Ku authored
There is a new mechanism which can do some real time performance tuning for WiFi and BT. This TX/RX info is a condition provide to firmware to do traffic analysis. Signed-off-by:
-
Ching-Te Ku authored
Remove WiFi traffic busy level & traffic rate from active role information. This information will move to v5 version TDMA cycle info. Signed-off-by:
-
Ching-Te Ku authored
The error map and counter can help to analyze is coexistence mechanism going well or not. For example, if there is E2G (External control Wi-Fi slot for Wi-Fi 2.4 GHz) hang counter, it means Wi-Fi firmware didn't cut a slot for Wi-Fi 2.4 GHz. Maybe something wrong with firmware timer. Signed-off-by:
-
Jacob Keller authored
Replace the calculations for the payload length in qtnf_cmd_band_fill_iftype with struct_size() and size_sub(). While the payload length does not get directly passed to an allocation function, the performed calculation is still calculating the size of a flexible array structure (minus the size of a header structure). Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Cc: Igor Mitsyanko <imitsyanko@quantenna.com> Cc: Sergey Matyukevich <geomatsi@gmail.com> Signed-off-by:
-
Jacob Keller authored
The ipw_fw_error structure contains a payload[] flexible array as well as two pointers to this array area, ->elem, and ->log. The total size of the allocated structure is computed without use of the <linux/overflow.h> macros. There's no reason to keep both a payload[] and an extra pointer to both the elem and log members. Convert the elem pointer member into the flexible array member, removing payload. Fix the allocation of the ipw_fw_error structure to use size_add(), struct_size(), and array_size() to compute the allocation. This ensures that any overflow saturates at SIZE_MAX rather than overflowing and potentially allowing an undersized allocation. Before the structure change, the layout of ipw_fw_error was: struct ipw_fw_error { long unsigned int jiffies; /* 0 8 */ u32 status; /* 8 4 */ u32 config; /* 12 4 */ u32 elem_len; /* 16 4 */ u32 log_len; /* 20 4 */ struct ipw_error_elem * elem; /* 24 8 */ struct ipw_event * log; /* 32 8 */ u8 payload[]; /* 40 0 */ /* size: 40, cachelines: 1, members: 8 */ /* last cacheline: 40 bytes */ }; After this change, the layout is now: struct ipw_fw_error { long unsigned int jiffies; /* 0 8 */ u32 status; /* 8 4 */ u32 config; /* 12 4 */ u32 elem_len; /* 16 4 */ u32 log_len; /* 20 4 */ struct ipw_event * log; /* 24 8 */ struct ipw_error_elem elem[]; /* 32 0 */ /* size: 32, cachelines: 1, members: 7 */ /* last cacheline: 32 bytes */ }; This saves a total of 8 bytes for every ipw_fw_error allocation, and removes the risk of a potential overflow on the allocation. Signed-off-by: -
Martin Kaiser authored
We can use the module_usb_driver macro instead of open-coding the driver's init and exit functions. This is simpler and saves some lines of code. Other realtek wireless drivers use module_usb_driver as well. Signed-off-by:
Martin Kaiser <martin@kaiser.cx> Reviewed-by:
-
Ping-Ke Shih authored
Originally, we keep RX standby timer to handle beamformee CSI, but this spends power and causes system not entering power save mode. To improve power consumption, release the timer if throughput becomes low. Signed-off-by:
-
Martin Kaiser authored
The Edimax V2 (vid 0x7392, pid 0xb811) works well with the rtl8xxxu driver since rtl8188eu support has been added. Remove the untested flag for this device. Signed-off-by:
-
Hans de Goede authored
Many devices ship with a nvram ccode value of X2/XT/XU/XV/ALL which are all special world-wide compatibility ccode-s. Most of these world-wide ccode-s allow passive scan mode only for 2.4GHz channels 12-14, only enabling them when an AP is seen on them. Since linux-firmware has moved to the new cyfmac4356-pci.bin + cyfmac4356-pci.clm_blob firmware files this no longer works and 4356 devices using e.g. an X2 ccode fail to connect to an AP on channel 13. Add the 4356 chip-id to the list of chips for which to use the ISO3166 country code + rev 0 as fallback in brcmf_translate_country_code() to fix this. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Kalle Valo authored
To clean up drivers/net/wireless move the old drivers drivers left in the directory to a new "legacy" directory. I did consider adding CONFIG_WLAN_VENDOR_LEGACY like other vendors have but then dropped the idea as these are really old drivers and hopefully we get to remove them soon. There should be no changes in compilation or in Kconfig options, merely moving files. Signed-off-by:
-
Kalle Valo authored
To clean up drivers/net/wireless move the virtual drivers to a new virtual directory. I did consider adding CONFIG_WLAN_VENDOR_VIRTUAL like other vendors have but then dropped the idea as we are not real drivers. There should be no changes in compilation or in Kconfig options, merely moving files. The order in menuconfig is slightly changed, the virtual drivers are now last in the list. Signed-off-by:
-
Aditya Kumar Singh authored
Add some more debug prints in processing regulatory WMI event in order to increase more debuggability. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Aditya Kumar Singh authored
In order to support different power levels of 6 GHz AP and client, new WMI event for regulatory - WMI_REG_CHAN_LIST_CC_EXT_EVENTID is added in firmware. This event provides new parameters required for 6 GHz regulatory rules. Add support for parsing 2.4 GHz, 5 GHz and 6 GHz reg rules and other parameters from WMI_REG_CHAN_LIST_CC_EXT_EVENTID. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Lavanya Suresh <quic_lavaks@quicinc.com> Signed-off-by:
Wen Gong <quic_wgong@quicinc.com> Signed-off-by:
-
Aditya Kumar Singh authored
Currently, during regulatory event, 2 GHz/5 GHz is referred to as 2G/5G including variable names. However, there is no such entity as 2G or 5G. Re-name such occurences to its proper name. No functional changes. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
