summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw88/main.c
AgeCommit message (Collapse)AuthorFilesLines
2024-09-02wifi: rtw88: assign mac_id for vif/sta and update to TX descPing-Ke Shih1-18/+12
A mac_id as an instance in firmware has to be assigned for each station including AP and connected stations. Firmware will use the mac_id to control TX rate and do statistics. Assignment rule is to assign mac_id to each vif when adding vif. For station mode, sta->mac_id will reuse vif->mac_id. For AP mode, dynamically allocate an sta->mac_id to a station, and vif->mac_id is used to send broadcast/multicast packets which are not belong to a station. For example, vif->mac_id sta->mac_id vif0 (STA mode) 0 0 vif1 (AP mode) 1 2... By the way, remove unused RTW_BC_MC_MACID, which was planed to send broadcast/multicast packets on fixed mac_id. Tested-on RTL8822CE with STA + AP SCC mode. Link: https://lore.kernel.org/linux-wireless/e4be0a75-43b2-4ae5-9aab-5c4a88e78097@gmail.com/ Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819025248.17939-1-pkshih@realtek.com
2024-08-09wifi: rtw88: Enable USB RX aggregation for 8822c/8822b/8821cBitterblue Smith1-4/+9
Enable USB RX aggregation when there is at least 1 Mbps RX or TX traffic, otherwise disable it. USB RX aggregation improves the RX speed of RTL8811CU on certain ARM systems, like the NanoPi NEO Core2. Before: 28 Mbps, after: 231 Mbps. It also improves the RX speed of RTL8822CU on some x86_64 systems. Before: ~200 Mbps, after: ~300 Mbps. The official drivers for these chips use the same logic for SDIO, but for some reason the SDIO driver in rtw88 always enables RX aggregation, so this patch only toggles aggregation for USB devices. RTL8703B is likely not found in USB devices, and RTL8723DU doesn't like aggregation. Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/b4c0d54c-6755-4b0f-9dd7-f9196fd74b68@gmail.com
2024-08-02wifi: rtw88: always wait for both firmware loading attemptsDmitry Antipov1-3/+4
In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN. Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Reported-by: syzbot+6c6c08700f9480c41fe3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6c6c08700f9480c41fe3 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240726114657.25396-1-dmantipov@yandex.ru
2024-07-31wifi: rtw88: debugfs: support multiple adapters debuggingPing-Ke Shih1-0/+1
Originally in order to read partial registers from large area, we write a range value stored into a static variable and read registers according to the static variable. However, if we install more than one adapters supported by this driver, the static variables will be overwritten by latter adapters. To resolve the problem, move the static variables to struct rtw_dev for each adapter. With changes, smatch spends too much time to parse rtw_debugfs_init(): debug.c:1289 rtw_debugfs_init() parse error: turning off implications after 60 seconds Move stuffs of adding debugfs entries to three rtw_debugfs_add_xxx() functions. Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Closes: https://lore.kernel.org/linux-wireless/cd6a2acf3c2c36d938b40140b52a779516f446a9.camel@realtek.com/T/#m27662022c70d9f893ba96f6c6a8dd8fce2434dfe Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240718064155.38955-1-pkshih@realtek.com
2024-07-17wifi: rtw88: Set efuse->ext_lna_5g - fix typoBitterblue Smith1-1/+1
efuse->ext_lna_2g is set twice and efuse->ext_lna_5g is not set at all. Set each one once. Nothing uses these members right now. They will be used by the RTL8821AU and RTL8812AU drivers. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8ccc9e13-0d45-417d-8f88-93a0ad294f77@gmail.com
2024-04-03wifi: rtw88: remove unsupported interface type of mesh pointPing-Ke Shih1-2/+1
Mesh point was added during development, but not remove at first submission, so it should not work properly. Remove it to reflect correct supported features. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240329114403.5539-1-pkshih@realtek.com
2024-03-29wifi: rtw88: station mode only for SDIO chipsPing-Ke Shih1-5/+9
Since only station mode has been tested on SDIO chips, only keep it support for SDIO chips to reflect correct supported features. Link: https://lore.kernel.org/linux-wireless/87wmpu1do6.fsf@kernel.org/T/#t Link: https://lore.kernel.org/linux-wireless/36972ff5-0c48-4bd2-8f9a-9649bfa24225@lexina.in/ Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240327004155.7172-1-pkshih@realtek.com
2024-03-26wifi: rtw88: coex: Prevent doing I/O during Wi-Fi power savingChing-Te Ku1-3/+2
Fix Wi-Fi 2.4Ghz throughput drop over than 40% when Bluetooh is idle. The code flow will read registers during Wi-Fi power saving, and be returned, which results in incorrect counters to do mechanism judgment. Adjust the code flow. Will leave Wi-Fi power save mode first then update counters. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240320075047.31810-1-pkshih@realtek.com
2024-03-05wifi: rtw88: 8821c: Fix beacon loss and disconnectBitterblue Smith1-2/+0
Tenda U9 V2.0, which contains RTL8811CU, is practically unusable because of frequent disconnections: Feb 23 14:46:45 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS Feb 23 14:46:46 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED bssid=90:55:de:__:__:__ reason=4 locally_generated=1 Feb 23 14:46:52 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-CONNECTED - Connection to 90:55:de:__:__:__ completed [id=0 id_str=] Feb 23 14:46:54 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS Feb 23 14:46:55 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED bssid=90:55:de:__:__:__ reason=4 locally_generated=1 Feb 23 14:47:01 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-CONNECTED - Connection to 90:55:de:__:__:__ completed [id=0 id_str=] Feb 23 14:47:04 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS Feb 23 14:47:05 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED bssid=90:55:de:__:__:__ reason=4 locally_generated=1 This is caused by a mistake in the chip initialisation. This version of the chip requires loading an extra AGC table right after the main one, but the extra table is being loaded at the wrong time, in rtw_chip_board_info_setup(). Move the extra AGC table loading to the right place, in rtw_phy_load_tables(). The rtw_chip_board_info_setup() can only do "software" things, and rtw_phy_load_tables() can really do IO. Fixes: 5d6651fe8583 ("rtw88: 8821c: support RFE type2 wifi NIC") 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/276c31d8-b9a8-4e54-a3ac-09b74657aff7@gmail.com
2023-12-12wifi: rtw88: Use random MAC when efuse MAC invalidChris Morgan1-0/+5
When the MAC address read from the efuse data is invalid, warn the user and use a random MAC address instead. On a device I am currently using (Anbernic RG-ARC) with a rtw8821cs the efuse appears to be incompletely/improperly programmed. The MAC address reads as ff:ff:ff:ff:ff:ff. When networkmanager attempts to initiate a connection (and I haven't hard-coded a MAC address or set it to random) it fails to establish a connection. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231208150739.129753-1-macroalpha82@gmail.com
2023-07-25wifi: rtw88: simplify vif iteratorsDmitry Antipov1-5/+3
Since all iterators called by 'rtw_iterate_vifs()' never uses 'mac' argument, it may be omitted, and 'struct rtw_vifs_entry' may be simplified accordingly. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230628072327.167196-4-dmantipov@yandex.ru
2023-07-25wifi: rtw88: remove unused and set but unused leftoversDmitry Antipov1-1/+0
Drop unused and set but unused 'last_push' of 'struct rtw_txq', 'wireless_set' of 'struct rtw_sta_info', 'usb_txagg_num' of 'struct rtw_usb' and 'n' of 'struct rx_usb_ctrl_block', unused definition of 'struct rtw_timer_list', adjust related code. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230628072327.167196-2-dmantipov@yandex.ru
2023-07-25wifi: rtw88: delete timer and free skb queue when unloadingDmitry Antipov1-1/+3
Fix possible crash and memory leak on driver unload by deleting TX purge timer and freeing C2H queue in 'rtw_core_deinit()', shrink critical section in the latter by freeing COEX queue out of TX report lock scope. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230628072327.167196-1-dmantipov@yandex.ru
2023-06-21wifi: rtw88: fix not entering PS mode after AP stopsPo-Hao Huang1-0/+8
Without this patch, firmware only track beacons for port 0 and since we will always start AP on port 0, this results in misbehavior of power saving mode on other ports after AP stops. The "default port" H2C command is used to notify which port should firmware track. Update the correct settings to firmware so power saving mode can work properly. 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/20230616125540.36877-7-pkshih@realtek.com
2023-06-21wifi: rtw88: Stop high queue during scanPo-Hao Huang1-2/+5
When traversing channel list, TX in high queue should be disabled along with beacon function, so packets won't be sent to incorrect channels. 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/20230616125540.36877-5-pkshih@realtek.com
2023-06-01wifi: rtw88: correct PS calculation for SUPPORTS_DYNAMIC_PSPing-Ke Shih1-2/+2
This driver relies on IEEE80211_CONF_PS of hw->conf.flags to turn off PS or turn on dynamic PS controlled by driver and firmware. Though this would be incorrect, it did work before because the flag is always recalculated until the commit 28977e790b5d ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS") is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS of hw->conf.flags if driver sets SUPPORTS_DYNAMIC_PS. Correct this by doing recalculation while BSS_CHANGED_PS is changed and interface is added or removed. It is allowed to enter PS only if single one station vif is working. Without this fix, driver doesn't enter PS anymore that causes higher power consumption. Fixes: bcde60e599fb ("rtw88: remove misleading module parameter rtw_fw_support_lps") Cc: stable@vger.kernel.org # 6.1+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527082939.11206-2-pkshih@realtek.com
2023-05-12wifi: rtw88: use work to update rate to avoid RCU warningPing-Ke Shih1-0/+15
The ieee80211_ops::sta_rc_update must be atomic, because ieee80211_chan_bw_change() holds rcu_read lock while calling drv_sta_rc_update(), so create a work to do original things. Voluntary context switch within RCU read-side critical section! WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x571/0x5d0 CPU: 0 PID: 4621 Comm: kworker/u16:2 Tainted: G W OE Workqueue: phy3 ieee80211_chswitch_work [mac80211] RIP: 0010:rcu_note_context_switch+0x571/0x5d0 Call Trace: <TASK> __schedule+0xb0/0x1460 ? __mod_timer+0x116/0x360 schedule+0x5a/0xc0 schedule_timeout+0x87/0x150 ? trace_raw_output_tick_stop+0x60/0x60 wait_for_completion_timeout+0x7b/0x140 usb_start_wait_urb+0x82/0x160 [usbcore usb_control_msg+0xe3/0x140 [usbcore rtw_usb_read+0x88/0xe0 [rtw_usb rtw_usb_read8+0xf/0x10 [rtw_usb rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core drv_sta_rc_update+0x7c/0x160 [mac80211 ieee80211_chan_bw_change+0xfb/0x110 [mac80211 ieee80211_change_chanctx+0x38/0x130 [mac80211 ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211 ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211 ieee80211_chswitch_work+0x95/0x170 [mac80211 process_one_work+0x201/0x410 worker_thread+0x4a/0x3b0 ? process_one_work+0x410/0x410 kthread+0xe1/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Cc: stable@vger.kernel.org Fixes: c1edc86472fc ("rtw88: add ieee80211:sta_rc_update ops") Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Link: https://lore.kernel.org/linux-wireless/f1e31e8e-f84e-3791-50fb-663a83c5c6e9@lwfinger.net/T/#t Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230508085429.46653-1-pkshih@realtek.com
2023-04-20wifi: rtw88: set pkg_type correctly for specific rtw8821c variantsSascha Hauer1-1/+1
According to the vendor driver the pkg_type has to be set to '1' for some rtw8821c variants. As the pkg_type has been hardcoded to '0', add a field for it in struct rtw_hal and set this correctly in the rtw8821c part. With this parsing of a rtw_table is influenced and check_positive() in phy.c returns true for some cases here. The same is done in the vendor driver. However, this has no visible effect on the driver here. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230417140358.2240429-4-s.hauer@pengutronix.de
2023-04-20wifi: rtw88: 8822c: add iface combinationPo-Hao Huang1-0/+25
Allow 8822c to operate two interface concurrently, only 1 AP mode plus 1 station mode under same frequency is supported. Combination of other types will not be added until requested. 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/20230414121331.18062-1-pkshih@realtek.com
2023-04-20wifi: rtw88: handle station mode concurrent scan with AP modePo-Hao Huang1-0/+39
This patch allows vifs sharing same hardware with the AP mode vif to do scan, do note that this could lead to packet loss or disconnection of the AP's clients. Since we don't have chanctx, update scan info upon set channel so bandwidth changes won't go unnoticed and get misconfigured after scan. Download beacon just before scan starts to allow hardware to get proper content to do beaconing. Last, beacons should only be transmitted in AP's operating channel. Turn related beacon functions off while we're in other channels so the receiving stations won't get confused. 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/20230414121323.18008-1-pkshih@realtek.com
2023-04-20wifi: rtw88: disallow PS during AP modePo-Hao Huang1-1/+1
Firmware can't support PS mode during AP mode, so disallow this case. 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/20230414121135.17828-5-pkshih@realtek.com
2023-04-20wifi: rtw88: add port switch for AP modePo-Hao Huang1-0/+79
Switch port settings if AP mode does not start on port 0 because of hardware limitation. For some ICs, beacons on ports other than zero could misbehave and do not issue properly, to fix this we change AP VIFs to port zero when multiple interfaces is active. 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/20230414121135.17828-3-pkshih@realtek.com
2023-04-20wifi: rtw88: add bitmap for dynamic port settingsPo-Hao Huang1-0/+1
In order to support multiple interfaces, multiple port settings will be required. Current code always uses port 0 and should be changed. Declare a bitmap with size equal to hardware port number to record the current usage. 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/20230414121135.17828-2-pkshih@realtek.com
2023-04-12wifi: rtw88: main: Reserve 8 bytes of extra TX headroom for SDIO cardsMartin Blumenstingl1-1/+3
For SDIO host controllers with DMA support the TX buffer physical memory address need to be aligned at an 8-byte boundary. Reserve 8 bytes of extra TX headroom so we can align the data without re-allocating the transmit buffer. While here, also remove the TODO comment regarding extra headroom for USB and SDIO. For SDIO the extra headroom is now handled and for USB it was not needed so far. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230405200729.632435-6-martin.blumenstingl@googlemail.com
2023-04-12wifi: rtw88: main: Add the {cpwm,rpwm}_addr for SDIO based chipsetsMartin Blumenstingl1-0/+5
Initialize the rpwm_addr and cpwm_addr for power-saving support on SDIO based chipsets. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230405200729.632435-5-martin.blumenstingl@googlemail.com
2023-01-16wifi: rtw88: Use rtw_iterate_vifs() for rtw_vif_watch_dog_iter()Martin Blumenstingl1-2/+4
USB and (upcoming) SDIO support may sleep in the read/write handlers. Make rtw_watch_dog_work() use rtw_iterate_vifs() to prevent "scheduling while atomic" or "Voluntary context switch within RCU read-side critical section!" warnings when accessing the registers using an SDIO card (which is where this issue has been spotted in the real world but it also affects USB cards). Fixes: 78d5bf925f30 ("wifi: rtw88: iterate over vif/sta list non-atomically") Suggested-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230108211324.442823-3-martin.blumenstingl@googlemail.com
2022-12-08wifi: rtw88: Add common USB chip supportSascha Hauer1-0/+4
Add the common bits and pieces to add USB support to the RTW88 driver. This is based on https://github.com/ulli-kroll/rtw88-usb.git which itself is first written by Neo Jou. Signed-off-by: neo_jou <neo_jou@realtek.com> Signed-off-by: Hans Ulli Kroll <linux@ulli-kroll.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202081224.2779981-8-s.hauer@pengutronix.de
2022-12-08wifi: rtw88: Drop coex mutexSascha Hauer1-2/+0
coex->mutex is used in rtw_coex_info_request() only. Most callers of this function hold rtwdev->mutex already, except for one callsite in the debugfs code. The debugfs code alone doesn't justify the extra lock, so acquire rtwdev->mutex there as well and drop the now unnecessary spinlock. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202081224.2779981-6-s.hauer@pengutronix.de
2022-12-08wifi: rtw88: Drop h2c.lockSascha Hauer1-1/+0
The h2c.lock spinlock is used in rtw_fw_send_h2c_command() and rtw_fw_send_h2c_packet(). Most callers call this with rtwdev->mutex held, except from one callsite in the debugfs code. The debugfs code alone doesn't justify the extra lock, so acquire rtwdev->mutex in debugfs and drop the now unnecessary spinlock. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202081224.2779981-5-s.hauer@pengutronix.de
2022-12-08wifi: rtw88: Drop rf_lockSascha Hauer1-1/+0
The rtwdev->rf_lock spinlock protects the rf register accesses in rtw_read_rf() and rtw_write_rf(). Most callers of these functions hold rtwdev->mutex already with the exception of the callsites in the debugfs code. The debugfs code doesn't justify an extra lock, so acquire the mutex there as well before calling rf register accessors and drop the now unnecessary spinlock. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202081224.2779981-4-s.hauer@pengutronix.de
2022-12-08wifi: rtw88: print firmware type in info messageSascha Hauer1-1/+3
It's confusing to read two different firmware versions in the syslog for the same device: rtw_8822cu 2-1:1.2: Firmware version 9.9.4, H2C version 15 rtw_8822cu 2-1:1.2: Firmware version 9.9.11, H2C version 15 Print the firmware type in this message to make clear these are really two different firmwares for different purposes: rtw_8822cu 1-1.4:1.2: WOW Firmware version 9.9.4, H2C version 15 rtw_8822cu 1-1.4:1.2: Firmware version 9.9.11, H2C version 15 Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202081224.2779981-2-s.hauer@pengutronix.de
2022-09-02wifi: rtw88: add missing destroy_workqueue() on error path in rtw_core_init()Yang Yingliang1-2/+6
Add the missing destroy_workqueue() before return from rtw_core_init() in error path. Fixes: fe101716c7c9 ("rtw88: replace tx tasklet with work queue") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220826023817.3908255-1-yangyingliang@huawei.com
2022-08-26wifi: rtw88: fix uninitialized use of primary channel indexPing-Ke Shih1-2/+1
clang reports uninitialized use: >> drivers/net/wireless/realtek/rtw88/main.c:731:2: warning: variable 'primary_channel_idx' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: ^~~~~~~ drivers/net/wireless/realtek/rtw88/main.c:754:39: note: uninitialized use occurs here hal->current_primary_channel_index = primary_channel_idx; ^~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw88/main.c:687:24: note: initialize the variable 'primary_channel_idx' to silence this warning u8 primary_channel_idx; ^ = '\0' This situation could not happen, because possible channel bandwidth 20/40/80MHz are enumerated. Fixes: 341dd1f7de4c ("wifi: rtw88: add the update channel flow to support setting by parameters") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20220815062004.22920-1-pkshih@realtek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-08-10wifi: rtw88: add the update channel flow to support setting by parametersChih-Kang Chang1-67/+97
In order to set channel info to hal during HW scan, we add the update channel flow to support setting by parameters to meet the HW scan requriement. Signed-off-by: Chih-Kang Chang <gary.chang@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/20220809084107.38137-4-pkshih@realtek.com
2022-08-09wifi: rtw88: access chip_info by const pointerPing-Ke Shih1-14/+14
Since chip_info has became const table, we must access them via const pointer to avoid invalid writing. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220727065232.28510-1-pkshih@realtek.com
2022-08-09wifi: rtw88: 8822c: extend supported probe request sizePo-Hao Huang1-1/+20
Some WSC IEs require size larger than we current supports. Extend size to fit those demands. Separate the registered scan IE length by IC so settings can be independent. Since old firmware uses fewer page number, define a firmware feature to be compatible with various firmware version. 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/20220727065003.28340-2-pkshih@realtek.com
2022-07-29wifi: rtw88: check the return value of alloc_workqueue()William Dean1-0/+4
The function alloc_workqueue() in rtw_core_init() can fail, but there is no check of its return value. To fix this bug, its return value should be checked with new error handling code. Fixes: fe101716c7c9d ("rtw88: replace tx tasklet with work queue") Reported-by: Hacash Robot <hacashRobot@santino.com> Signed-off-by: William Dean <williamsukatube@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220723063756.2956189-1-williamsukatube@163.com
2022-06-20wifi: mac80211: make some SMPS code MLD-awareJohannes Berg1-2/+2
Start making some SMPS related code MLD-aware. This isn't really done yet, but again cuts down our 'deflink' reliance. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-06-20wifi: mac80211: move interface config to new structJohannes Berg1-4/+9
We'll use bss_conf for per-link configuration later, so move out all the non-link-specific data out into a new struct ieee80211_vif_cfg used in the vif. Some adjustments were done with the following spatch: @@ expression sdata; struct ieee80211_vif *vifp; identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator }; @@ ( -sdata->vif.bss_conf.var +sdata->vif.cfg.var | -vifp->bss_conf.var +vifp->cfg.var ) @bss_conf@ struct ieee80211_bss_conf *bss_conf; identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator }; @@ -bss_conf->var +vif_cfg->var (though more manual fixups were needed, e.g. replacing "vif_cfg->" by "vif->cfg." in many files.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-06-10Merge tag 'wireless-next-2022-06-10' of ↵Jakub Kicinski1-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== wireless-next patches for v5.20 Here's a first set of patches for v5.20. This is just a queue flush, before we get things back from net-next that are causing conflicts, and then can start merging a lot of MLO (multi-link operation, part of 802.11be) code. Lots of cleanups all over. The only notable change is perhaps wilc1000 being the first driver to disable WEP (while enabling WPA3). * tag 'wireless-next-2022-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (29 commits) wifi: mac80211_hwsim: Directly use ida_alloc()/free() wifi: mac80211: refactor some key code wifi: mac80211: remove cipher scheme support wifi: nl80211: fix typo in comment wifi: virt_wifi: fix typo in comment rtw89: add new state to CFO state machine for UL-OFDMA rtw89: 8852c: add trigger frame counter ieee80211: add trigger frame definition wifi: wfx: Remove redundant NULL check before release_firmware() call wifi: rtw89: support MULTI_BSSID and correct BSSID mask of H2C wifi: ray_cs: Drop useless status variable in parse_addr() wifi: ray_cs: Utilize strnlen() in parse_addr() wifi: rtw88: use %*ph to print small buffer wifi: wilc1000: add IGTK support wifi: wilc1000: add WPA3 SAE support wifi: wilc1000: remove WEP security support wifi: wilc1000: use correct sequence of RESET for chip Power-UP/Down wifi: rtlwifi: fix error codes in rtl_debugfs_set_write_h2c() wifi: rtw88: Fix Sparse warning for rtw8821c_hw_spec wifi: rtw88: Fix Sparse warning for rtw8723d_hw_spec ... ==================== Link: https://lore.kernel.org/r/20220610142838.330862-1-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-30rtw88: fix null vif pointer when hw_scan failsPo-Hao Huang1-1/+4
Add this check to avoid crash by dereferencing a null pointer. When hwscan fails due to no memory or dma failure, the scan flag in ieee80211_local is cleared. So mac80211 determine that it's not hw_scan then calls sw_scan_complete() with null vif, which is also freed during the fail. 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/20220520081523.45987-1-pkshih@realtek.com
2022-05-30wifi: rtw88: add a work to correct atomic scheduling warning of ::set_timPing-Ke Shih1-0/+2
The set_tim is supposed to be atomic, but we should download beacon context to firmware with a mutex lock. To avoid warning, do the thing in another work. BUG: scheduling while atomic: swapper/1/0/0x00000700 Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W 5.18.0-rc7-00703-g33b5ee09a0c1 #4 Hardware name: Pine64 RK3566 Quartz64-A Board (DT) Call trace: dump_backtrace.part.0+0xc4/0xd0 show_stack+0x14/0x60 dump_stack_lvl+0x60/0x78 dump_stack+0x14/0x2c __schedule_bug+0x5c/0x70 __schedule+0x5c4/0x630 schedule+0x44/0xb0 schedule_preempt_disabled+0xc/0x14 __mutex_lock.constprop.0+0x538/0x56c __mutex_lock_slowpath+0x10/0x20 mutex_lock+0x54/0x60 rtw_ops_set_tim+0x20/0x40 __sta_info_recalc_tim+0x150/0x250 sta_info_recalc_tim+0x10/0x20 invoke_tx_handlers_early+0x4e4/0x5c0 ieee80211_tx+0x78/0x110 ieee80211_xmit+0x94/0xc0 __ieee80211_subif_start_xmit+0x818/0xd20 ieee80211_subif_start_xmit+0x44/0x2d0 dev_hard_start_xmit+0xd0/0x150 __dev_queue_xmit+0x250/0xb30 dev_queue_xmit+0x10/0x20 br_dev_queue_push_xmit+0x94/0x174 br_forward_finish+0x90/0xa0 __br_forward+0xc0/0x13c br_forward+0x108/0x134 br_dev_xmit+0x1cc/0x3a4 dev_hard_start_xmit+0xd0/0x150 __dev_queue_xmit+0x250/0xb30 dev_queue_xmit+0x10/0x20 arp_xmit+0x6c/0x7c arp_send_dst+0x8c/0xc0 arp_solicit+0xd4/0x1e0 neigh_probe+0x58/0xa0 neigh_timer_handler+0x27c/0x380 call_timer_fn.constprop.0+0x20/0x80 __run_timers.part.0+0x230/0x280 run_timer_softirq+0x38/0x70 _stext+0x104/0x278 __irq_exit_rcu+0xa4/0xdc irq_exit_rcu+0xc/0x14 el1_interrupt+0x34/0x50 el1h_64_irq_handler+0x14/0x20 el1h_64_irq+0x64/0x68 arch_cpu_idle+0x14/0x20 do_idle+0x208/0x290 cpu_startup_entry+0x20/0x30 secondary_start_kernel+0x130/0x144 __secondary_switched+0x54/0x58 Fixes: f2217968ffda ("rtw88: Add update beacon flow for AP mode") Reported-by: Ondřej Jirman <megi@xff.cz> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Ondřej Jirman <megi@xff.cz> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220526051251.281905-1-pkshih@realtek.com
2022-05-01rtw88: add HT MPDU density value for each chipChih-Kang Chang1-1/+2
Each chip have best ampdu density value, the correct setting can improve throughput performance. Signed-off-by: Chih-Kang Chang <gary.chang@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/20220428020521.8015-1-pkshih@realtek.com
2022-04-12rtw88: Add update beacon flow for AP modePo-Hao Huang1-0/+6
To support stations in power saving mode, AP should notify stations that there are frames buffered at the AP via TIM during beacons. Driver used to transmit identical beacons that were downloaded to hardware during the initiation phase. This beacon will become obsolete over time. If the beacon does not contain sufficient information, station would not be able to percept that there is data to receive. Hence it won't wake up and start the PS-poll procedure, this could lead to timeout and/or lost data segments. In order to resolve this issue, driver will now download beacon to hardware whenever the content is updated. Enable hardware to update dtim_count for more efficiency, this reduces the overhead of downloading beacon at every beacon interval since most of the time only the dtim_count needs to be updated. Change queue mapping for broadcast/multicast frames to high queue, so these frames can be prioritized and sent when dtim_count is zero. 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/20220407095858.46807-4-pkshih@realtek.com
2022-04-12rtw88: add ieee80211:sta_rc_update opsPo-Hao Huang1-3/+4
Adding this allows us to get notification when bitrate configuration of the station changes. Update according parameters to firmware so the rate control algorithm can work properly. 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/20220407095858.46807-2-pkshih@realtek.com
2022-04-11mac80211: prepare sta handling for MLO supportSriram R1-25/+25
Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-06rtw88: change idle mode condition during hw_scanPo-Hao Huang1-3/+4
Previously we only consider single interface's status, idle mode behavior could be unexpected when multiple interfaces is active. Change to enter/leave idle mode by mac80211's configuration state. 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/20220318034316.40720-1-pkshih@realtek.com
2022-02-22rtw88: change rtw_info() to proper message levelPing-Ke Shih1-4/+4
Larry reported funny log entries [1] when he used rtl8821ce. These messages are not harmless, but not useful for users, so change them to rtw_dbg() level. By the way, I review all rtw_info() and change others to rtw_warn(). [1] https://lore.kernel.org/linux-wireless/c356d5ae-a7b3-3065-1121-64c446e70333@lwfinger.net/ Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218035527.9835-1-pkshih@realtek.com
2022-02-21rtw88: coex: Add C2H/H2C handshake with BT mailbox for asking HID InfoChing-Te Ku1-0/+1
In order to recognize the gaming controller HID, make a C2H/H2C/Mailbox handshake to collect all the connected information from BT. Signed-off-by: Ching-Te Ku <ku920601@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/20220215004855.4098-6-pkshih@realtek.com
2022-02-21rtw88: coex: update BT PTA counter regularlyChing-Te Ku1-0/+2
If BT PTA counter can not update regularly, it will lead coex mechanism run into some unexpected state. Signed-off-by: Ching-Te Ku <ku920601@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/20220215004855.4098-4-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-07 16:00:33 +0300