summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2024-08-09wifi: rtw88: usb: Support RX aggregationBitterblue Smith1-21/+40
The chips can be configured to aggregate several frames into a single USB transfer. Modify rtw_usb_rx_handler() to support this case. RX aggregation improves the RX speed of RTL8811CU on certain ARM systems, like the NanoPi NEO Core2. It also improves the RX speed of RTL8822CU on some x86_64 systems. Currently none of the chips are configured to aggregate frames. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> 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/f845826d-de71-492d-9a22-e48c07989a1f@gmail.com
2024-08-09wifi: rtw88: usb: Update the RX stats after every frameBitterblue Smith1-0/+1
Update the number of received unicast data frames and bytes every time a frame is received. This is what the PCI and SDIO drivers do. This has an influence on the power saving, bluetooth coexistence, and (in a future patch) the use of RX aggregation. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. 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/75a2ca52-8f01-45c5-926f-d3a68ae3b284@gmail.com
2024-08-09wifi: rtw88: usb: Init RX burst length according to USB speedBitterblue Smith2-1/+28
This is needed in order to make USB RX aggregation work with RTL8811CU (and presumably RTL8822BU and RTL8822CU also). I don't know what BIT_DMA_BURST_CNT, BIT_DMA_MODE, and BIT_DROP_DATA_EN are doing. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. The RX speed is unchanged in my tests. 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/ac569c6f-7129-4341-b523-901fe10cabff@gmail.com
2024-08-09wifi: rtl8xxxu: add missing rtl8192cu USB IDsPeter Robinson1-0/+6
The rtl8xxxu has all the rtl8192cu USB IDs except for the following 3 so add them to the untested section so they can be used with the rtl8xxxu as the rtl8192cu are well supported. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240806082233.3837436-1-pbrobinson@gmail.com
2024-08-09wifi: rtl8xxxu: drop reference to staging driversPeter Robinson1-3/+2
The Kconfig notes mention staging drivers that have since been removed so update the driver's description so it no longer references the staging rtl8723au and rtl8192u drivers which have now been deleted. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805221910.3765214-1-pbrobinson@gmail.com
2024-08-09wifi: rtw89: wow: add net-detect support for 8852cChin-Yen Lee1-1/+3
Enable net-detect in WoWLan stub of 8852c, and declare net-detect support up to 8 SSIDs. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-6-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: add delay option for net-detectChin-Yen Lee4-3/+27
The delay option is the period in unit of second for WoWLAN firmware to wait before the first scan. We get the option from cfg80211 and practice it. Another, in some platform, WoWLAN firmware may found configured network and then trigger resume process, before suspend process is completed, lead to the wakeup function failed. So the default value is set one to avoid the issue. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-5-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: add WoWLAN net-detect supportChin-Yen Lee9-78/+568
Net-detect is an option of WoWLAN to allow the device to be woken up from suspend mode when configured network is detected. When user enables net-detect and lets the device enter suspend state, WoWLAN firmware will periodically scan until beacon or probe response of configured networks are received. If configured networks are detected, WoWLAN firmware will trigger resume process. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-4-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: implement PS mode for net-detectChin-Yen Lee4-7/+89
When net-detect is enabled, WoWLAN firmware will periodically scan until beacon or probe response of configured networks are received. To reduce power consumption, the FW-IPS mode is implemented to keep WiFi chip in idle mode between each scan. The FW-IPS is controlled by WoWLAN firmware to turn of some critical electrical components, and is different from the original IPS mode which most electrical components are turned off. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-3-pkshih@realtek.com
2024-08-09wifi: rtw89: 8852c: support firmware format up to v1Ping-Ke Shih1-2/+2
Driver has supported different WoWLAN reason code by commit 0e5210217768 ("wifi: rtw89: wow: update WoWLAN reason register for different FW") since firmware version 0.27.80.0. The old driver can't support two kinds of WoWLAN reason, so increase firmware format to v1. Also driver tables of BB and RF registers and power values will be added into v1 format. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-2-pkshih@realtek.com
2024-08-07wifi: rtw89: correct VHT TX rate on 20MHz connectionDian-Syuan Yang1-2/+5
It may get wrong bitrate when connecting to AP set VHT 20MHz, and thus we fix it to follow Wi-Fi spec. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-6-pkshih@realtek.com
2024-08-07wifi: rtw89: add support for HW encryption in unicast management framesKuan-Chung Chen10-15/+40
Add hardware encryption support for unicast management frames for 8922AE and 8852CE. Other chips will continue to use software encryption for unicast management frames. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-5-pkshih@realtek.com
2024-08-07wifi: rtw89: avoid to add interface to list twice when SERChih-Kang Chang2-1/+21
If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: <TASK> ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]--- Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-4-pkshih@realtek.com
2024-08-07wifi: rtw89: 8922a: Add new fields for scan offload H2C commandPo-Hao Huang4-6/+28
Update scan offload H2C format to fit firmware version 35.21. The new fields indicate lengths of variable length members, so when driver and firmware are using mismatch version, FW could handle the parsing better. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-3-pkshih@realtek.com
2024-08-07wifi: rtw89: 8922a: new implementation for RFK pre-notify H2CKuan-Chung Chen3-22/+53
For firmware version 0.35.31 and above, update H2C RFK pre-notify to new implementation. Rename existing H2C to v0 for backward compatibility. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-2-pkshih@realtek.com
2024-08-02wifi: rtw89: pass chanctx_idx to rtw89_btc_{path_}phymap()Zong-Zhe Yang7-37/+39
Originally, rtw89_btc_phymap() and rtw89_btc_path_phymap() access chan with hard-code RTW89_CHANCTX_0. But, they are problematic when the chip supports multiple channels. So, change their prototype and pass chanctx_idx ahead. Let callers still pass RTW89_CHANCTX_0 for now, but we will refine callers in the following. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-8-pkshih@realtek.com
2024-08-02wifi: rtw89: fw: correct chan access in assoc_cmac_tbl_g7 and update_beacon_beZong-Zhe Yang1-2/+2
Originally, these H2C commands access chan with hard-code RTW89_CHANCTX_0. They are problematic when the chip supports multiple channels. So, correct them by accessing right chan under rtwvif. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-7-pkshih@realtek.com
2024-08-02wifi: rtw89: pass rtwvif to RFK scanZong-Zhe Yang8-16/+24
For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_scan prototype and pass rtwvif ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-6-pkshih@realtek.com
2024-08-02wifi: rtw89: pass rtwvif to RFK channelZong-Zhe Yang9-17/+18
For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_channel prototype and pass rtwvif ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-5-pkshih@realtek.com
2024-08-02wifi: rtw89: rename sub_entity to chanctxZong-Zhe Yang24-223/+223
Originally, we planed to fill MAC_0/1 indicators with chanctx and use sub_entity_xxx for these things. However, there are some reasons listed below which make us give up this plan after we know our Wi-Fi 7 HW design. 1. one link is bound to one HW band during its life time but, one link might change chanctx dynamically 2. in concurrent mode, assume 1st vif is MLD 1st vif's 2nd link might use the same chanctx as 2nd vif but, they are not on the same HW band So, we let sub_entity_xxx stuffs deal with only chanctx now. And, to be more readable, we rename sub_entity related words to chanctx. No logic is changed. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-4-pkshih@realtek.com
2024-08-02wifi: rtw89: mcc: stop at a role holding chanctxZong-Zhe Yang3-6/+38
In general, MCC (multi-channel concurrency) stops when some chanctx is unassigned. Originally, we let FW to stop at a fixed role. However, it might be the one to be unassigned. So, iterate MCC roles and select one which is still holding chanctx. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-3-pkshih@realtek.com
2024-08-02wifi: rtw89: chan: refine MCC re-plan flow when unassign chanctxZong-Zhe Yang1-12/+25
Originally during unassign-chanctx, MCC (multi-channel concurrency) is re-planed before set-channel if need. But, we might calculate MCC stuffs based on old channel info. And, the following set-channel might be racing with FW MCC state mechanism. So, we refine this flow. Now, if MCC re-plan is needed here, it will be done after set-channel. Besides, to be more rigorous, we now ensure entity isn't paused before we deal with MCC things here. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-2-pkshih@realtek.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-08-02wifi: rtw89: fix typo of rtw89_phy_ra_updata_XXXZong-Zhe Yang3-7/+7
`updata` should be `update` Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-5-pkshih@realtek.com
2024-08-02wifi: rtw89: 885xb: reset IDMEM mode to prevent download firmware failurePing-Ke Shih1-1/+1
For different firmware type, it could change IDMEM mode, so reset it to default to avoid encountering error for RTL8851B/RTL8852B/RTL8852BT if that kind of firmware was downloaded before. rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.3, cmd version 0, type 5 rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.3, cmd version 0, type 3 rtw89_8851be 0000:02:00.0: MAC has already powered on rtw89_8851be 0000:02:00.0: fw security fail rtw89_8851be 0000:02:00.0: download firmware fail rtw89_8851be 0000:02:00.0: [ERR]fwdl 0x1E0 = 0x62 rtw89_8851be 0000:02:00.0: [ERR]fwdl 0x83F2 = 0x8 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f524 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f500 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f53c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f508 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f534 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f534 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f508 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f53c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f524 rtw89_8851be 0000:02:00.0: failed to setup chip information rtw89_8851be: probe of 0000:02:00.0 failed with error -16 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-4-pkshih@realtek.com
2024-08-02wifi: rtw89: add support for hardware rfkillKuan-Chung Chen10-0/+184
Add support for ieee80211::rfkill_poll ops. This enables periodic monitoring of the hardware rfkill state, triggering updates when the status changes. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-3-pkshih@realtek.com
2024-08-02wifi: rtw89: add EVM statistics for 1SS rateKuan-Chung Chen4-13/+52
To more accurately debug performance issues, EVM statistics will differentiate between different space streams, and only beacon and data frames will be included. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-2-pkshih@realtek.com
2024-08-02wifi: rtw88: 8822c: Parse channel from IE to correct invalid hardware reportsPo-Hao Huang7-3/+63
For CCK packets we could get incorrect reports from hardware. And this causes wrong frequencies being reported. Parse the channel information from IE if provided by AP to fix this. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724050501.7550-1-pkshih@realtek.com
2024-07-31wifi: rtw88: 8703b: Fix reported RX band widthBitterblue Smith1-1/+1
The definition of GET_RX_DESC_BW is incorrect. Fix it according to the GET_RX_STATUS_DESC_BW_8703B macro from the official driver. Tested only with RTL8812AU, which uses the same bits. Cc: stable@vger.kernel.org Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Tested-by: Fiona Klute <fiona.klute@gmx.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1cfed9d5-4304-4b96-84c5-c347f59fedb9@gmail.com
2024-07-31wifi: rtw88: 8822c: Fix reported RX band widthBitterblue Smith1-4/+6
"iw dev wlp2s0 station dump" shows incorrect rx bitrate: tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2 rx bitrate: 86.7 MBit/s VHT-MCS 9 VHT-NSS 1 This is because the RX band width is calculated incorrectly. Fix the calculation according to the phydm_rxsc_2_bw() function from the official drivers. After: tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2 rx bitrate: 390.0 MBit/s VHT-MCS 9 80MHz VHT-NSS 1 It also works correctly with the AP configured for 20 MHz and 40 MHz. Tested with RTL8822CE. Cc: stable@vger.kernel.org Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/bca8949b-e2bd-4515-98fd-70d3049a0097@gmail.com
2024-07-31wifi: rtw89: 8852bt: add 8852BE-VT to Makefile and KconfigPing-Ke Shih2-0/+23
RTL8852BE-VT is a WiFi 6 2x2 chip, which can operate on 2/5 GHz channels and 80MHz bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-8-pkshih@realtek.com
2024-07-31wifi: rtw89: 8852bte: add PCI entry of 8852BE-VTPing-Ke Shih1-0/+93
PCI device ID 10ec:b520 of RTL8852BE-VT is added as PCI entry, and define chip capabilities for driver common routines. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-7-pkshih@realtek.com
2024-07-31wifi: rtw89: 8852bt: declare firmware features of RTL8852BTPing-Ke Shih1-0/+4
Firmware features are enabled after being supported, including TX wake, firmware crash simulation, hardware scan. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-6-pkshih@realtek.com
2024-07-31wifi: rtw89: 8852bt: add chip_ops of RTL8852BTPing-Ke Shih2-0/+463
Add chip_info of RTL8852BT accordingly, including power on/off function, BB reset, TSSI settings while setting channel, RF calibration, and BT coexistence. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-5-pkshih@realtek.com
2024-07-31wifi: rtw89: 8852bt: add chip_info of RTL8852BTPing-Ke Shih6-4/+455
Add chip_info of RTL8852BT accordingly, including firmware elements support, MAC memory quota (WDE, PLE and etc), SER IMR used by firmware, BTC registers, register based H2C/C2H, WoWLAN stub. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-4-pkshih@realtek.com
2024-07-31wifi: rtw89: 8852bt: rfk: use predefined string choice for DPK enable/disablePing-Ke Shih1-1/+1
clang warns precedence of '?:' and '&'. Even though original logic is correct, use str_enable_disable() to avoid clang confusing. Another way to fix is to add parentheses around '&', but I choose former one. >> drivers/net/wireless/realtek/rtw89/rtw8852bt_rfk.c:1827:46: warning: operator '?:' has lower precedence than '&'; '&' will be evaluated first [-Wbitwise-conditional-parentheses] 1827 | kidx, dpk->is_dpk_enable & off_reverse ? "enable" : "disable"); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407200741.dMG9uvHU-lkp@intel.com/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-3-pkshih@realtek.com
2024-07-31wifi: rtw89: 8852bt: add set_channel_rfPing-Ke Shih2-0/+229
Add RF part of set_channel() is to configure RF registers, and then hardware can TX/RX on specified frequency and bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-2-pkshih@realtek.com
2024-07-31wifi: rtw89: select WANT_DEV_COREDUMPZong-Zhe Yang1-0/+1
We have invoked device coredump when fw crash. Should select WANT_DEV_COREDUMP by ourselves. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240718070616.42217-2-pkshih@realtek.com
2024-07-31wifi: rtw88: select WANT_DEV_COREDUMPZong-Zhe Yang1-0/+1
We have invoked device coredump when fw crash. Should select WANT_DEV_COREDUMP by ourselves. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240718070616.42217-1-pkshih@realtek.com
2024-07-31wifi: rtw88: debugfs: support multiple adapters debuggingPing-Ke Shih4-129/+180
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: 8821cu: Remove VID/PID 0bda:c82cNick Morrow1-2/+0
Remove VID/PID 0bda:c82c as it was inadvertently added to the device list in driver rtw8821cu. This VID/PID is for the rtw8822cu device and it is already in the appropriate place for that device. Cc: stable@vger.kernel.org Signed-off-by: Nick Morrow <morrownr@gmail.com> 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/335d7fa1-0ba5-4b86-bba5-f98834ace1f8@gmail.com
2024-07-17wifi: rtw88: usb: Support USB 3 with RTL8822CU/RTL8822BUBitterblue Smith8-12/+116
The Realtek wifi 5 devices which support USB 3 are weird: when first plugged in, they pretend to be USB 2. The driver needs to send some commands to the device, which make it disappear and come back as a USB 3 device. Implement the required commands in rtw88. When a USB 3 device is plugged into a USB 2 port, rtw88 will try to switch it to USB 3 mode only once. The device will disappear and come back still in USB 2 mode, of course. Some people experience heavy interference in the 2.4 GHz band in USB 3 mode, so add a module parameter switch_usb_mode with the default value 1 to let people disable the switching. 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/77906c62-5674-426f-bde1-1b2a12a0339d@gmail.com
2024-07-17wifi: rtw89: 8852bt: rfk: Fix spelling mistake "KIP_RESOTRE" -> "KIP_RESTORE"Colin Ian King1-1/+1
There is a spelling mistake in a literal string. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240710112253.228171-1-colin.i.king@gmail.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-07-12net: mctp-i2c: invalidate flows immediately on TX errorsJeremy Kerr1-0/+41
If we encounter an error on i2c packet transmit, we won't have a valid flow anymore; since we didn't transmit a valid packet sequence, we'll have to wait for the key to timeout instead of dropping it on the reply. This causes the i2c lock to be held for longer than necessary. Instead, invalidate the flow on TX error, and release the i2c lock immediately. Cc: Bonnie Lo <Bonnie_Lo@wiwynn.com> Tested-by: Jerry C Chen <Jerry_C_Chen@wiwynn.com> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-12net: netconsole: Eliminate redundant setting of enabled fieldBreno Leitao1-2/+1
When disabling a netconsole target, enabled_store() is called with enabled=false. Currently, this results in updating the nt->enabled field twice: 1. Inside the if/else block, with the target_list_lock spinlock held 2. Later, without the target_list_lock This patch eliminates the redundancy by setting the field only once, improving efficiency and reducing potential race conditions. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240709144403.544099-3-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-12net: netconsole: Remove unnecessary cast from boolBreno Leitao1-1/+1
The 'enabled' variable is already a bool, so casting it to its value is redundant. Remove the superfluous cast, improving code clarity without changing functionality. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240709144403.544099-2-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-12bna: adjust 'name' buf size of bna_tcb and bna_ccb structuresAlexey Kodanev2-6/+7
To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace. Fixes: 8b230ed8ec96 ("bna: Brocade 10Gb Ethernet device driver") Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-07-12Merge tag 'wireless-next-2024-07-11' of ↵Jakub Kicinski142-3348/+15828
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.11 Most likely the last "new features" pull request for v6.11 with changes both in stack and in drivers. The big thing is the multiple radios for wiphy feature which makes it possible to better advertise radio capabilities to user space. mt76 enabled MLO and iwlwifi re-enabled MLO, ath12k and rtw89 Wi-Fi 6 devices got WoWLAN support. Major changes: cfg80211/mac80211 * remove DEAUTH_NEED_MGD_TX_PREP flag * multiple radios per wiphy support mac80211_hwsim * multi-radio wiphy support ath12k * DebugFS support for datapath statistics * WCN7850: support for WoW (Wake on WLAN) * WCN7850: device-tree bindings ath11k * QCA6390: device-tree bindings iwlwifi * mvm: re-enable Multi-Link Operation (MLO) * aggregation (A-MSDU) optimisations rtw89 * preparation for RTL8852BE-VT support * WoWLAN support for WiFi 6 chips * 36-bit PCI DMA support mt76 * mt7925 Multi-Link Operation (MLO) support * tag 'wireless-next-2024-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (204 commits) wifi: mac80211: fix AP chandef capturing in CSA wifi: iwlwifi: correctly reference TSO page information wifi: mt76: mt792x: fix scheduler interference in drv own process wifi: mt76: mt7925: enabling MLO when the firmware supports it wifi: mt76: mt7925: remove the unused mt7925_mcu_set_chan_info wifi: mt76: mt7925: update mt7925_mac_link_bss_add for MLO wifi: mt76: mt7925: update mt7925_mcu_bss_basic_tlv for MLO wifi: mt76: mt7925: update mt7925_mcu_set_timing for MLO wifi: mt76: mt7925: update mt7925_mcu_sta_phy_tlv for MLO wifi: mt76: mt7925: update mt7925_mcu_sta_rate_ctrl_tlv for MLO wifi: mt76: mt7925: add mt7925_mcu_sta_eht_mld_tlv for MLO wifi: mt76: mt7925: update mt7925_mcu_sta_update for MLO wifi: mt76: mt7925: update mt7925_mcu_add_bss_info for MLO wifi: mt76: mt7925: update mt7925_mcu_bss_mld_tlv for MLO wifi: mt76: mt7925: update mt7925_mcu_sta_mld_tlv for MLO wifi: mt76: mt7925: add mt7925_[assign,unassign]_vif_chanctx wifi: mt76: add def_wcid to struct mt76_wcid wifi: mt76: mt7925: report link information in rx status wifi: mt76: mt7925: update rate index according to link id wifi: mt76: mt7925: add link handling in the mt7925_ipv6_addr_change ... ==================== Link: https://patch.msgid.link/20240711102353.0C849C116B1@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski17-54/+128
Cross-merge networking fixes after downstream PR. Conflicts: net/sched/act_ct.c 26488172b029 ("net/sched: Fix UAF when resolving a clash") 3abbd7ed8b76 ("act_ct: prepare for stolen verdict coming from conntrack and nat engine") No adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-23 13:46:14 +0300