- 01 Jul, 2022 3 commits
-
-
Mauro Carvalho Chehab authored
The lack of the colon makes it not parse the function parameter: include/net/mac80211.h:6250: warning: Function parameter or member 'vif' not described in 'ieee80211_channel_switch_disconnect' Fix it. Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://lore.kernel.org/r/11c1bdb861d89c93058fcfe312749b482851cbdb.1656409369.git.mchehab@kernel.orgSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Mauro Carvalho Chehab authored
There are currently 17 kernel-doc warnings on this file: include/net/cfg80211.h:391: warning: Function parameter or member 'bw' not described in 'ieee80211_eht_mcs_nss_supp' include/net/cfg80211.h:437: warning: Function parameter or member 'eht_cap' not described in 'ieee80211_sband_iftype_data' include/net/cfg80211.h:507: warning: Function parameter or member 's1g' not described in 'ieee80211_sta_s1g_cap' include/net/cfg80211.h:1390: warning: Function parameter or member 'counter_offset_beacon' not described in 'cfg80211_color_change_settings' include/net/cfg80211.h:1390: warning: Function parameter or member 'counter_offset_presp' not described in 'cfg80211_color_change_settings' include/net/cfg80211.h:1430: warning: Enum value 'STATION_PARAM_APPLY_STA_TXPOWER' not described in enum 'station_parameters_apply_mask' include/net/cfg80211.h:2195: warning: Function parameter or member 'dot11MeshConnectedToAuthServer' not described in 'mesh_config' include/net/cfg80211.h:2341: warning: Function parameter or member 'short_ssid' not described in 'cfg80211_scan_6ghz_params' include/net/cfg80211.h:3328: warning: Function parameter or member 'kck_len' not described in 'cfg80211_gtk_rekey_data' include/net/cfg80211.h:3698: warning: Function parameter or member 'ftm' not described in 'cfg80211_pmsr_result' include/net/cfg80211.h:3828: warning: Function parameter or member 'global_mcast_stypes' not described in 'mgmt_frame_regs' include/net/cfg80211.h:4977: warning: Function parameter or member 'ftm' not described in 'cfg80211_pmsr_capabilities' include/net/cfg80211.h:5742: warning: Function parameter or member 'u' not described in 'wireless_dev' include/net/cfg80211.h:5742: warning: Function parameter or member 'links' not described in 'wireless_dev' include/net/cfg80211.h:5742: warning: Function parameter or member 'valid_links' not described in 'wireless_dev' include/net/cfg80211.h:6076: warning: Function parameter or member 'is_amsdu' not described in 'ieee80211_data_to_8023_exthdr' include/net/cfg80211.h:6949: warning: Function parameter or member 'sig_dbm' not described in 'cfg80211_notify_new_peer_candidate' Address them, in order to build a better documentation from this header. Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://lore.kernel.org/r/f6f522cdc716a01744bb0eae2186f4592976222b.1656409369.git.mchehab@kernel.orgSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Peter Chiu authored
S1g action frame with code 22 is not protected so update the robust action frame list. Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Link: https://lore.kernel.org/r/20220622010820.17522-1-chui-hao.chiu@mediatek.comSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 21 Jun, 2022 13 commits
-
-
Ping-Ke Shih authored
The DPK is a kind of RF calibration whose algorithm is to fine tune parameters and calibrate, and check the result. If the result isn't good enough, it could adjust parameters and try again. This issue is to read and show the result, but it could be a negative calibration result that causes divisor 0 and core dump. So, fix it by phy_div() that does division only if divisor isn't zero; otherwise, zero is adopted. divide error: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1 <HASH:d024 28> RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core] RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 00000000000180fc RDI: ffffa141d01023c0 RBP: ffffa9bb412a76a0 R08: 0000000000001319 R09: 00000000ffffff92 R10: ffffffffc0292de3 R11: ffffffffc00d2f51 R12: 0000000000000000 R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638 FS: 00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000013e8e010 CR3: 0000000110d2c000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: rtw89_core_sta_add+0x95/0x9c [rtw89_core <HASH:d239 29>] rtw89_ops_sta_state+0x5d/0x108 [rtw89_core <HASH:d239 29>] drv_sta_state+0x115/0x66f [mac80211 <HASH:81fe 30>] sta_info_insert_rcu+0x45c/0x713 [mac80211 <HASH:81fe 30>] sta_info_insert+0xf/0x1b [mac80211 <HASH:81fe 30>] ieee80211_prep_connection+0x9d6/0xb0c [mac80211 <HASH:81fe 30>] ieee80211_mgd_auth+0x2aa/0x352 [mac80211 <HASH:81fe 30>] cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 <HASH:00cd 31>] nl80211_authenticate+0x2e5/0x306 [cfg80211 <HASH:00cd 31>] genl_rcv_msg+0x371/0x3a1 ? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 <HASH:00cd 31>] ? genl_rcv+0x36/0x36 netlink_rcv_skb+0x8a/0xf9 genl_rcv+0x28/0x36 netlink_unicast+0x27b/0x3a0 netlink_sendmsg+0x2aa/0x469 sock_sendmsg_nosec+0x49/0x4d ____sys_sendmsg+0xe5/0x213 __sys_sendmsg+0xec/0x157 ? syscall_enter_from_user_mode+0xd7/0x116 do_syscall_64+0x43/0x55 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fa99f6e689b Fixes: e3ec7017 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220613065144.15647-1-pkshih@realtek.com
-
Po-Hao Huang authored
Previously we only disable invalid reports for 52A, since we plan to support more ICs in the future, enable settings for those as well. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-12-pkshih@realtek.com
-
Ping-Ke Shih authored
TX BD (TX ring index) and TX WD (WiFi descriptor buffer) are freed asynchronously. With burst packets, we free TX WD, but the corresponding TX BD couldn't be freed yet. Then, TX can possibly get stuck due to no more TX BD. To avoid this, ignore reclaiming TX BD only if TX WD is no free space, because at this moment TX BD must have some spaces. Otherwise, we reclaim TX BD to resolve TX stuck issue. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-11-pkshih@realtek.com
-
Ping-Ke Shih authored
In low power mode, regular IO is power off, so we don't schedule napi to poll RX and TX completion. Therefore, calling ieee80211_rx_napi() with napi instance causes long RX latency. To fix this, use NULL as argument, and then it can use netif_receive_skb_list() to receive. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-10-pkshih@realtek.com
-
Ping-Ke Shih authored
Somehow, firmware could report invalid TX rate, and we consider the invalid rate as 0 that will make a wrong decision. So, drop invalid reports, and also suppress the warning message. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-9-pkshih@realtek.com
-
Ping-Ke Shih authored
Some warning messages could bother users. With proper handling, these situations don't really affect usage, but we still need to keep monitor these messages. If they happen frequently, we must review driver or hardware design to clarify. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-8-pkshih@realtek.com
-
Kuan-Chung Chen authored
To improve VO throughput, we enable VO TX AMPDU. We measure the latency of enable or disable VO TX AMPDU. The experimental results show that the difference between the two is insignificant only 300µs, so the little impact can be ignored for user experience. Moreover, we found some APs will have a group key handshake timeout issue when the EAPOL's TID is already setup BA session. Therefore, when transmitting EAPOL, if EAPOL's TID BA session is already setup, we need to delete it. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-7-pkshih@realtek.com
-
Kuan-Chung Chen authored
The potential TX stuck occurs when there are lots of packets to be transmitted and the boundary of the tx_resource is hit. Add this patch to avoid the TX stuck when burst traffic. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-6-pkshih@realtek.com
-
Ping-Ke Shih authored
Since we can allocate MAC ID, BSSID and address CAM to TDLS peer, declare we can support TDLS now. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-5-pkshih@realtek.com
-
Ping-Ke Shih authored
In STA mode, if peer is TDLS. Allocate a BSSID CAM entry with peer's address to match address properly, and then hardware can ACK peer's packets and receive packets to driver. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-4-pkshih@realtek.com
-
Ping-Ke Shih authored
Normally, we allocate a BSSID CAM to a vif. By hardware design, we must allocate a BSSID CAM to each TDLS peer, so separate BSSID CAM operations that will be used by later patches. This patch doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-3-pkshih@realtek.com
-
Ping-Ke Shih authored
Normally, we only allocate an address CAM and single one MAC ID to AP in STA mode. To support TDLS, we handle TDLS peers like AP handles stations. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-2-pkshih@realtek.com
-
Alexey Kodanev authored
As a result of the execution of the inner while loop, the value of 'idx' can be equal to LINK_QUAL_MAX_RETRY_NUM. However, this is not checked after the loop and 'idx' is used to write the LINK_QUAL_MAX_RETRY_NUM size array 'lq_cmd->rs_table[idx]' below in the outer loop. The fix is to check the new value of 'idx' inside the nested loop, and break both loops if index equals the size. Checking it at the start is now pointless, so let's remove it. Detected using the static analysis tool - Svace. Fixes: be663ab6 ("iwlwifi: split the drivers for agn and legacy devices 3945/4965") Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220608171614.28891-1-aleksei.kodanev@bell-sw.com
-
- 20 Jun, 2022 24 commits
-
-
Veerendranath Jakkam authored
The MLO links used for connection with an MLD AP are decided by the driver in case of SME offloaded to driver. Add support for the drivers to indicate the information of links used for MLO connection in connect and roam callbacks, update the connected links information in wdev from connect/roam result sent by driver. Also, send the connected links information to userspace. Add a netlink flag attribute to indicate that userspace supports handling of MLO connection. Drivers must not do MLO connection when this flag is not set. This is to maintain backwards compatibility with older supplicant versions which doesn't have support for MLO connection. Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
Print the link ID in link_info_changed function. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add initial support to hwsim for creating MLO-capable radios dynamically (and statically via module parameter, but that's not really recommended.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When retrieving scan data, expose not just whether or not the interface (possibly an MLD) is associated to the BSS or not, but also on which link ID if it is an MLD. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When getting/dumping an interface, expose information about valid links. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
Add to hwsim a link_data structure. For now, move the beacon interval and beacon timer to the link_data structure (making them per link). Set a beacon timer for each link and transmit a per link beacon (pass the link_id to ieee80211_beacon_get). Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We should set the STA deflink addresses in case no link is really added. Fixes: 046d2e7c ("mac80211: prepare sta handling for MLO support") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Maintain a hash table of link-sta addresses so we can find them for management frames etc. where addresses haven't been replaced by the drivers to the MLD address yet. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We need to be able to access these in a race-free way under traffic while adding/removing them, so RCU-ify the pointers. This requires passing a link_sta to a lot of functions so we don't have to do the RCU handling everywhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Hardcoding link[0] is more confusing than using deflink, so use deflink for now, which requires making the macro a bit safer. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This is only used in rx.c, so move it into the file. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
Pass the link id through to the get_beacon and return the beacon for a specific link id. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
In start_ap and stop_ap mac80211 callbacks pass the link_id to the drivers. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
Use link and link_conf according to the link_id provided by cfg in start_ap/stop_ap and change_beacon. Also use them in the functions called by them. Note that for a non MLD device, the link_id is 0, and link[0] and link_conf[0] equal to deflink and bss_conf respectively (what was there before). Also, call vif_info_change for BSS related changes (SSID), and link_info_change for LINK related changes (instead of the legacy bss_info_change). Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When a link is added or removed via nl80211, these are called. Implement them so we don't have to check in all the different per-link commands whether we've already created the necessary datastructures. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add some optional callbacks for link add/remove so that drivers can react here. Initially, I thought it would be sufficient to just create the link in start_ap etc., but it turns out that's not so simple, since there are quite a few callbacks that can be called: if they're erroneously without start_ap, things might crash. Thus it might be easier for drivers to allocate all the necessary data structures immediately, to not have to worry about it in each callback, since cfg80211 checks that the link ID is valid (has been added.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We wanted to have this sorted by direction (to/from driver), but didn't maintain that well. Sort the file now. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add the necessary infrastructure, including a new driver method, to add/remove links to/from a station. To do this, refactor the link alloc/free a bit, splitting that so we can do it without linking them, to handle failures better. Note that a station entry must be created representing an MLD or a non-MLD STA, it cannot change between the two. When representing an MLD, the 'deflink' is used for the first link, which might be removed later, in which case the memory isn't reused. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Take a few bits out of the control.flags to add the link ID to TX frame metadata, so drivers don't need to look it up by the address themselves. Implement that lookup where it's needed, for internal frame TX, and set it to "unspecified" for data transmissions. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the interface is an MLD, then we don't know which band the frame will be transmitted on, and we don't know how to look up the band. Set the band information to zero in that case, the driver cannot rely on it anyway. No longer inline ieee80211_tx_skb_tid() since it's even bigger now. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add the necessary infrastructure, including a new driver method, to add/remove links to/from an interface. Also add the missing link address to bss_conf (which we use as link_conf too), and fill it, in station mode for now just randomly, in AP mode we get the address from cfg80211 since the link must be created with an address first. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
For authentication, we need the BSS, the link_id and the AP MLD address to create the link and station, (for now) the driver assigns a link address and sends the frame, the MLD address needs to be the address of the interface. For association, pass the list of BSSes that were selected for the MLO connection, along with extra per-STA profile elements, the AP MLD address and the link ID on which the association request should be sent. Note that for now we don't have a proper way to pass the link address(es) and so the driver/mac80211 will select one, but depending on how that selection works it means that assoc w/o auth data still being around (mac80211 implementation detail) the association won't necessarily work - so this will need to be extended in the future to sort out the link addressing. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When channel contexts are used, IEEE80211_CONF_CHANGE_SMPS doesn't make sense and doesn't apply (which is documented). Mask it in this case. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
Replace the bss_info_changed callback with vif_cfg_changed and link_info_changed callbacks (for vif changes and link changes). Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-