- 09 Jul, 2024 34 commits
-
-
Sean Wang authored
Extend mt7925_mcu_uni_bss_bcnft with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
Deren Wu <deren.wu@mediatek.com> Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20240613030241.5771-21-sean.wang@kernel.orgSigned-off-by:
Felix Fietkau <nbd@nbd.name>
-
Sean Wang authored
The channel context has to be bound with the per-link BSS, thus, we extend mt7925_mcu_[abort, set]_roc to work with the per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_set_bss_pm with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_bss_basic_tlv with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_bss_sec_tlv with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
remove unused parameters in mt7925_mcu_bss_bmc_tlv Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_bss_bmc_tlv with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_bss_mld_tlv with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_bss_qos_tlv with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_bss_he_tlv with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_bss_color_tlv with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_bss_ifs_tlv with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_set_timing with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt7925_mcu_add_bss_info with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Deren Wu authored
Extend mt7925_mcu_set_tx with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. Co-developed-by:
-
Sean Wang authored
Extend mt76_connac_mcu_uni_add_dev with per-link BSS configuration. The patch we created is a prerequisite to enable the MLO function in the driver. It is purely a refactoring patch so the functionality should remain unchanged. We also extend link_idx field in mt76_connac_bss_basic_tlv for the firmware to able to identify the link index in the MLO mode that is not harmful for the current non-MLO mode. Signed-off-by:
-
Deren Wu authored
The .bss_info_changed method is being split into .vif_cfg_changed and .link_info_changed to support MLD devices, but it will still support non-MLD devices. Co-developed-by:
-
Deren Wu authored
We are introducing a new structure, mt792x_chanctx, to quickly identify the linked BSS it is working on. This eliminates the need to search in mt7921_ctx_iter() or mt7925_ctx_iter() when the channel context changes. Co-developed-by:
-
Deren Wu authored
We are introducing a new structure, mt792x_link_sta, to manage per-link configurations in preparation for future station (STA) support of Multi-Link Operation (MLO). This patch only includes structural changes and does not involve any logic changes. We have moved relevant parameters, such as the wcid from the mt76_wcid structure, from the mt7921x_sta structure to the mt792x_link_sta structure. For current drivers that do not support MLO, there is only one link STA, and link information is accessed via the deflink member. However, we have not yet created the per-link BSS configuration indexed by link ID for Multi-Link Device (MLD) support in mt7921x_sta. This step needs to be completed before adding MLD support for STA mode. Co-developed-by:
-
Deren Wu authored
We are introducing a new structure, mt792x_bss_conf, to manage per-link configurations in preparation for future STA support of Multi-Link Operation (MLO). The patch does not include any logic changes, only structural changes. We have moved relevant parameters from the mt7921x_vif structure such as to mt76 of mt76_vif structure, rssi and Tx queue parameters to mt7921x_bss_conf structure. We can access those members to configure the BSS for this interface, whether it is our own BSS or the one we are associated with. However, we have not yet created the per-link BSS configuration indexed by link ID for Multi-Link Device (MLD) support. This step needs to be extended before adding MLD support for AP mode. Co-developed-by:
-
https://github.com/pkshih/rtwKalle Valo authored
rtw-next patches for v6.11 Some cleanups of rtl8xxxu and rtlwifi, and some fixes of rtw88. The major change is to develop WoWLAN and preparation of RTL8852BE-VT listed below: rtw89: - preparation of RTL8852BE-VT * add RF calibration code * move shared code with RTL8852BE to common module - add WoWLAN for WiFi 6 chips - support 36-bit PCI DMA -
Chen Ni authored
Replace kmalloc() + memset() to kzalloc() for better code readability and simplicity. Signed-off-by:
Chen Ni <nichen@iscas.ac.cn> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240704090622.2260102-1-nichen@iscas.ac.cn
-
Sascha Hauer authored
mwifiex_get_priv_by_id() returns the priv pointer corresponding to the bss_num and bss_type, but without checking if the priv is actually currently in use. Unused priv pointers do not have a wiphy attached to them which can lead to NULL pointer dereferences further down the callstack. Fix this by returning only used priv pointers which have priv->bss_mode set to something else than NL80211_IFTYPE_UNSPECIFIED. Said NULL pointer dereference happened when an Accesspoint was started with wpa_supplicant -i mlan0 with this config: network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" } When waiting for the AP to be established, interrupting wpa_supplicant with <ctrl-c> and starting it again this happens: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000 | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18 | Hardware name: somemachine (DT) | Workqueue: events sdio_irq_work | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex] | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157 | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Call trace: | mwifiex_get_cfp+0xd8/0x15c [mwifiex] | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex] | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex] | mwifiex_process_sta_event+0x298/0xf0c [mwifiex] | mwifiex_process_event+0x110/0x238 [mwifiex] | mwifiex_main_process+0x428/0xa44 [mwifiex] | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio] | process_sdio_pending_irqs+0x64/0x1b8 | sdio_irq_work+0x4c/0x7c | process_one_work+0x148/0x2a0 | worker_thread+0x2fc/0x40c | kthread+0x110/0x114 | ret_from_fork+0x10/0x20 | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ end trace 0000000000000000 ]--- Signed-off-by:Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by:
-
Felix Fietkau authored
This registers one wiphy radio per supported band. Number of different channels is set per radio. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Felix Fietkau authored
Validate number of channels and interface combinations per radio. Assign each channel context to a radio. Signed-off-by:
-
Felix Fietkau authored
Reduces indentation in preparation for further changes Signed-off-by:
-
Felix Fietkau authored
Add support for counting global and per-radio max/current number of channels, as well as checking radio-specific interface combinations. Signed-off-by:
-
Felix Fietkau authored
Will be used to explicitly assign a channel context to a wiphy radio. Signed-off-by:
-
Felix Fietkau authored
DFS can be supported with multi-channel combinations, as long as each DFS capable radio only supports one channel. Signed-off-by:
-
Felix Fietkau authored
Check if the full channel width is in the radio's frequency range. Signed-off-by:
-
Felix Fietkau authored
Add a field in struct iface_combination_params to check per-radio interface combinations instead of per-wiphy ones. Signed-off-by:
-
Felix Fietkau authored
The prerequisite for MLO support in cfg80211/mac80211 is that all the links participating in MLO must be from the same wiphy/ieee80211_hw. To meet this expectation, some drivers may need to group multiple discrete hardware each acting as a link in MLO under single wiphy. With this change, supported frequencies and interface combinations of each individual radio are reported to user space. This allows user space to figure out the limitations of what combination of channels can be used concurrently. Even for non-MLO devices, this improves support for devices capable of running on multiple channels at the same time. Signed-off-by:
-
Zong-Zhe Yang authored
Chanctx emulation didn't info IEEE80211_CONF_CHANGE_CHANNEL to drivers during ieee80211_restart_hw (ieee80211_emulate_add_chanctx). It caused non-chanctx drivers to not stand on the correct channel after recovery. RX then behaved abnormally. Finally, disconnection/reconnection occurred. So, set IEEE80211_CONF_CHANGE_CHANNEL when in_reconfig. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Link: https://patch.msgid.link/20240709073531.30565-1-kevin_yang@realtek.com Cc: stable@vger.kernel.org Fixes: 0a44dfc0 ("wifi: mac80211: simplify non-chanctx drivers") Signed-off-by:
-
Johannes Berg authored
Looks like not all compilers allow strlen(constant) as a constant, so don't do that. Instead, revert back to defining the length as the first submission had it. Fixes: b5d14b0c ("wifi: virt_wifi: avoid reporting connection success with wrong SSID") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407090934.NnR1TUbW-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202407090944.mpwLHGt9-lkp@intel.com/Signed-off-by:
-
- 08 Jul, 2024 6 commits
-
-
Johannes Berg authored
WARN_ON("string") will unconditionally trigger a warning, but not really do what it may look like. Use WARN(1, ...) instead and add the mode number as well. Signed-off-by: -
Michael-CY Lee authored
Do not check BSS color collision in following cases 1. already under a color change 2. color change is disabled Signed-off-by:
Michael-CY Lee <michael-cy.lee@mediatek.com> Link: https://patch.msgid.link/20240705074346.11228-1-michael-cy.lee@mediatek.comSigned-off-by:
-
Michael-CY Lee authored
The color change finalize work might be called after the link is stopped, which might lead to a kernel crash. Signed-off-by:
-
En-Wei Wu authored
When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found). The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning. Fixed it by checking the SSID (from user space) in the connection code. Fixes: c7cdba31 ("mac80211-next: rtnetlink wifi simulation device") Reported-by: syzbot+d6eb9cee2885ec06f5e3@syzkaller.appspotmail.com Signed-off-by:
En-Wei Wu <en-wei.wu@canonical.com> Link: https://patch.msgid.link/20240705023756.10954-1-en-wei.wu@canonical.comSigned-off-by:
-
Felix Fietkau authored
Avoid reusing stale driver data when an interface is brought down and up again. In order to avoid having to duplicate the memset in every single driver, do it here. Signed-off-by:
-
Felix Fietkau authored
Create a helper function that puts the data from struct ieee80211_iface_combination to a nl80211 message. This will be used for adding per-radio interface combination data. Signed-off-by:
-
