- 15 Feb, 2024 14 commits
-
-
Bitterblue Smith authored
And use the stored addresses in rtl8192cu instead of hardcoding them. This is what the vendor drivers do. Perhaps this is not strictly necessary for RTL8192CU devices. However, the dual mac version of RTL8192DU has two USB interfaces, each with its own set of endpoints. Hardcoding their addresses in the upcoming rtl8192du driver would require making some assumptions which I'm not qualified to make. Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/7b6a602a-6101-4bab-958d-bcff4d565b40@gmail.com
-
Bitterblue Smith authored
rtl8192cu handles 1T1R devices (RTL8188CUS), 1T2R devices (RTL8191CU), and 2T2R devices (RTL8192CU). The 2T2R devices were incorrectly detected as 1T2R because of a mistake in the IS_92C_1T2R macro. The visible effect of this is that the firmware was allowed to use TX rates only up to MCS7. Fix the IS_92C_1T2R macro. Now my 2T2R device has much better upload speed. Before: 46 Mbps. After: 82 Mbps. Also fix a debug message which was printing "RF_1T1R" even for 1T2R chips. Signed-off-by:
-
Ping-Ke Shih authored
The rcu_read_unlock() is accidentally added, and sparse warn: drivers/net/wireless/realtek/rtw89/fw.c:2807:17: warning: context imbalance in 'rtw89_fw_h2c_assoc_cmac_tbl_g7' - unexpected unlock Fixes: b82730bf ("wifi: cfg80211/mac80211: move puncturing into chandef") Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: -
Zong-Zhe Yang authored
We are going to allow MCC (multi-channel concurrency) on RTL8922A. So, increase 8922a::support_chanctx_num up to 2 first. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
On Wi-Fi 7 chips, concurrent stuffs are supported by FW MRC series (multi-role concurrent) functions. And, driver has implemented the corresponding SW handling in patches in front of this one. Now, we extend SW MCC (multi-channel concurrent) flow to work on Wi-Fi 7 chips. In SW point of view, things look as below. | SW | | FW func | | | | H2C/C2H | -------------------------------------------- | | ax | | | /----| FW MCC func | | MCC | -- chip --+ | | | \----| FW MRC func | | | be | Signed-off-by:
-
Zong-Zhe Yang authored
Implement MRC (multiple role concurrent) H2C commands. Mainly deal with H2C format, LE type built from CPU value, default setting on some fields, and then sending the command to FW. Besides, MRC start, MRC delete, and MRC request TSF need to wait for a report from C2H events. Signed-off-by:
-
Zong-Zhe Yang authored
Add handling of MRC (multiple role concurrent) C2H events including TSF report and status report. Parse report data and then complete the corresponding H2C commands, which will be implemented in the following. Signed-off-by:
-
Zong-Zhe Yang authored
For Wi-Fi 7 chips, FW supports MRC (multi-role concurrent) functions including H2C commands and C2H events. We can consider FW MRC functions as a superset of FW MCC (multi-channel concurrent) functions. And, MRC functions can take MLO things into account. Basically before MLO, SW can also manipulate FW MRC to work original SW MCC flow. So, we add them first and implement the handling in the following. And then, SW MCC will call different series of FW functions according to chip later. Signed-off-by:
-
David Mosberger-Tang authored
Previously, the driver created a net device (typically wlan0) as soon as the module was loaded. This commit changes the driver to follow normal Linux convention of creating the net device only when bus probing detects a supported chip. Signed-off-by:
David Mosberger-Tang <davidm@egauge.net> Tested-By:
Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by:
-
Alexis Lothoré authored
wilc_netdev_cleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver: echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind ================================================================== BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86 CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from print_report+0x154/0x500 print_report from kasan_report+0xac/0xd8 kasan_report from wilc_netdev_cleanup+0x508/0x5cc wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec wilc_bus_remove from spi_remove+0x8c/0xac spi_remove from device_release_driver_internal+0x434/0x5f8 device_release_driver_internal from unbind_store+0xbc/0x108 unbind_store from kernfs_fop_write_iter+0x398/0x584 kernfs_fop_write_iter from vfs_write+0x728/0xf88 vfs_write from ksys_write+0x110/0x1e4 ksys_write from ret_fast_syscall+0x0/0x1c [...] Allocated by task 1: kasan_save_track+0x30/0x5c __kasan_kmalloc+0x8c/0x94 __kmalloc_node+0x1cc/0x3e4 kvmalloc_node+0x48/0x180 alloc_netdev_mqs+0x68/0x11dc alloc_etherdev_mqs+0x28/0x34 wilc_netdev_ifc_init+0x34/0x8ec wilc_cfg80211_init+0x690/0x910 wilc_bus_probe+0xe0/0x4a0 spi_probe+0x158/0x1b0 really_probe+0x270/0xdf4 __driver_probe_device+0x1dc/0x580 driver_probe_device+0x60/0x140 __driver_attach+0x228/0x5d4 bus_for_each_dev+0x13c/0x1a8 bus_add_driver+0x2a0/0x608 driver_register+0x24c/0x578 do_one_initcall+0x180/0x310 kernel_init_freeable+0x424/0x484 kernel_init+0x20/0x148 ret_from_fork+0x14/0x28 Freed by task 86: kasan_save_track+0x30/0x5c kasan_save_free_info+0x38/0x58 __kasan_slab_free+0xe4/0x140 kfree+0xb0/0x238 device_release+0xc0/0x2a8 kobject_put+0x1d4/0x46c netdev_run_todo+0x8fc/0x11d0 wilc_netdev_cleanup+0x1e4/0x5cc wilc_bus_remove+0xc8/0xec spi_remove+0x8c/0xac device_release_driver_internal+0x434/0x5f8 unbind_store+0xbc/0x108 kernfs_fop_write_iter+0x398/0x584 vfs_write+0x728/0xf88 ksys_write+0x110/0x1e4 ret_fast_syscall+0x0/0x1c [...] David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needs_free_netdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list. Fix this use-after-free thanks to two mechanisms: - navigate in the list with list_for_each_entry_safe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with list_del_rcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev) Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vif_mutex lock), we do not need to use RCU list API, that's why we can benefit from list_for_each_entry_safe. [1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/ Fixes: 8399918f ("staging: wilc1000: use RCU list to maintain vif interfaces list") Signed-off-by:
-
Johannes Berg authored
Even if that's the same as IEEE80211_MAX_SSID_LEN, we really should just use IEEE80211_MAX_MESH_ID_LEN for mesh, rather than having the BUILD_BUG_ON()s. Signed-off-by:Johannes Berg <johannes.berg@intel.com>
-
Miri Korenblit authored
mac80211 might (due to an unavoidable race) cancel a ROC that has already expired. In that case the driver should not send the session protection cmd to cancel the ROC. When session protection is supported, the te_data::id field is reused to save the configuration id. Check it before sending the cmd. Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240205211151.30176bf869d9.Id811c20d3746b870cbe0c946bbfe1c0ab0a290cb@changeidSigned-off-by:
-
Miri Korenblit authored
This is set when a P2P ROC ends, and uses as an indication inside iwl_mvm_roc_done_wk that the resources used for this ROC (sta/link) needs to be flushed/deactivated (respectively). But we also have IWL_MVM_STATUS_ROC_RUNNING, which is set whenever P2P ROC starts, and is not even used in iwl_mvm_roc_done_wk. Use IWL_MVM_STATUS_ROC_RUNNING as an indicator, and remove the redundant bit. While at it, add a call to synchronize_net also for the AUX ROC case, which is missing in the existing code. Signed-off-by:
-
Johannes Berg authored
There's a conflict already and some upcoming changes also depend on changes in wireless for being conflict- free, so pull wireless in to make all that easier. Signed-off-by:
-
- 12 Feb, 2024 26 commits
-
-
Johannes Berg authored
There may be different hardware or configurations supported, so check for our own EMLSR capability before allowing it to be used, in addition to checking the AP's. Signed-off-by:
-
Miri Korenblit authored
Start supporting API version 89 for new devices. Signed-off-by:
-
Johannes Berg authored
Add missing kernel-doc, fix annotations, etc. Signed-off-by:
-
Johannes Berg authored
Add missing kernel-doc and otherwise fix things. Signed-off-by:
-
Johannes Berg authored
Some things are misnamed or missing, fix that. Signed-off-by:
-
Johannes Berg authored
Add missing and rename mismatched kernel-doc descriptions. Also just remove the unused IWL_FW_ERROR_DUMP_MAX constant. Signed-off-by:
-
Johannes Berg authored
This was misnamed, fix it. Also add a space to make it look cleaner. Signed-off-by:
-
Johannes Berg authored
With C99 bool we really also should use true/false, not the upper-case variants, wherever they may actually be coming from. Fix that. Signed-off-by:
-
Johannes Berg authored
The versioning here comes from the firmware, so it should be the same as in the firmware, fix that. Signed-off-by:
-
Ilan Peer authored
One of the flags was from the wrong API. Fixes: 9be162a7 ("wifi: iwlwifi: mvm: add support for the new MAC CTXT command") Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Ilan Peer authored
New additions to the P2P specification use action frames to extend the P2P device discovery and service discovery. Thus, configure the P2P Device link to accept all management frames. Signed-off-by:
-
Johannes Berg authored
The firmware will now start with 1500 byte A-MSDU size rather than 3500 as before, and that seems to cause some really hard to debug problems. Keep A-MSDU disabled if the size is less than 2000 to disable this for now. Signed-off-by:
-
Mukesh Sisodiya authored
6 GHz STA supports different power types as LPI, SP, VLP. and this information is provided by regulatory info. Add support in driver to parse the power type capability in regulatory info from FW and set it to the channel flags. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Reviewed-by:
Gregory Greenman <gregory.greenman@intel.com> Signed-off-by:
-
Shaul Triebitz authored
In MFP, do not disconnect if an unprotected deauth or disassoc was received during D3. For that, need to configure wowlan with MFP (IS_11W_ASSOC). Now, in case of an unprotected deauth/disassoc, the wakeup reason returned by the firmware will be: IWL_WAKEUP_BY_11W_UNPROTECTED_DEAUTH_OR_DISASSOC (and not IWL_WOWLAN_WAKEUP_BY_DISCONNECTION_ON_DEAUTH which will cause a disconnection). Also, report this reason to cfg80211. In another patch, the driver will send an SA query. Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
-
Shaul Triebitz authored
Add to cfg80211_wowlan_wakeup another wakeup reason - unprot_deauth_disassoc. To be set to true if the woke up was due to an unprotected deauth or disassoc frame in MFP. In that case report WOWLAN_TRIG_UNPROTECTED_DEAUTH_DISASSOC. Signed-off-by:
-
Shaul Triebitz authored
Add a report reason for waking up due to an unprotected deauth/disassoc when MFP is used. If setting wowlan to wake on disconnection, and an unprotected deatuh/disassoc arrived (in MFP), some drivers might want to report wakeup due to unprotected deauth/disassoc, rather than dissassociation. Add support for that. Signed-off-by:
-
Johannes Berg authored
If the driver uses the new IEEE80211_CHAN_CAN_MONITOR, we may monitor on channels that are, e.g. via regulatory, otherwise considered disabled. However, we really shouldn't transmit on them, so prevent that. Signed-off-by:
-
Johannes Berg authored
If the hardware supports a disabled channel, it may in some cases be possible to use monitor mode (without any transmit) on it when it's otherwise disabled. Add a new channel flag IEEE80211_CHAN_CAN_MONITOR that makes it possible for a driver to indicate such a thing. Make it per channel so drivers could have a choice with it, perhaps it's only possible on some channels, perhaps some channels are not supported at all, but still there and marked disabled. In _nl80211_parse_chandef() simplify the code and check only for an unknown channel, _cfg80211_chandef_usable() will later check for IEEE80211_CHAN_DISABLED anyway. Signed-off-by:
-
Johannes Berg authored
UHB stands for "Ultra High Band", but this term doesn't really exist in the spec. Rename all occurrences to "6 GHz", but keep a few defines for userspace API compatibility. Link: https://msgid.link/20240206164849.c9cfb9400839.I153db3b951934a1d84409c17fbe1f1d1782543fa@changeidSigned-off-by:
-
Andrei Otcheretianski authored
This allows testing 160MHz channels with DFS concurrent. While at it, remove the TODO for adding a module param to enable NL80211_EXT_FEATURE_DFS_CONCURRENT. This is not really needed as mac80211_hwsim still needs to be loaded with custom regdom. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
-
Aditya Kumar Singh authored
Currently, whenever AP link is brought down via ieee80211_stop_ap() function, all stations connected to the sdata are flushed. However, in case of MLO there is a requirement to flush only stations connected to that link and not all. For instance - Consider 2 GHz and 5 GHz are AP MLD. Now due to some reason 5 GHz link of this AP is going down (link removal or any other case). All stations connected, even legacy stations connected to 2 GHz link AP would also be flushed. Flushing of other link stations is not desirable. Fix this issue by passing self link ID to sta_flush() function. This would then only remove the stations which are still using the passed link ID as their link sta. Other stations will not be affected. Signed-off-by:
Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240205162952.1697646-4-quic_adisi@quicinc.comSigned-off-by:
-
Aditya Kumar Singh authored
Whenever sta_flush() function is invoked, all STAs present in that interface are flushed. In case of MLO, it is desirable to only flush such STAs that are at least using a given link id as one of their links. Add support for this by making change in the __sta_info_flush API argument to accept a link ID. And then, only if the STA is using the given link as one of its links, it would be flushed. Signed-off-by:
-
Aditya Kumar Singh authored
Currently whenever NL80211_CMD_DEL_STATION command is called without any MAC address, all stations present on that interface are flushed. However with MLO there is a need to flush such stations only which are using at least a particular link from the AP MLD interface. For example - 2 GHz and 5 GHz are part of an AP MLD. To this interface, following stations are connected - 1. One non-EHT STA on 2 GHz link. 2. One non-EHT STA on 5 GHz link. 3. One Multi-Link STA having 2 GHz and 5 GHz as active links. Now if currently, NL80211_CMD_DEL_STATION is issued by the 2 GHz link without any MAC address, it would flush all station entries. However, flushing of station entry #2 at least is not desireable since it is connected to 5 GHz link alone. Hence, add an option to pass link ID as well in the command so that if link ID is passed, stations using that passed link ID alone would be flushed and others will not. So after this, station entries #1 and #3 alone would be flushed and #2 will remain as it is. Signed-off-by:
-
Lorenzo Bianconi authored
Get rid of gfp parameter from ieee80211_obss_color_collision_notify since it is no longer used. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by:
-
Ping-Ke Shih authored
Since WiFi 7 is expected to support MLO, so we should enable MAC-0/1 and PHY-0/1. By default, set dbcc_en=true, change quota to DBCC mode, and set MLO mode to 2 + 0 that means we only use 2x2 connection on MAC/PHY-0 for now. Signed-off-by:
-
Po-Hao Huang authored
Reference the current quota mode to avoid misleading warnings. This patch is required after supporting DBCC quota mode. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
-
