summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/realtek/rtw88/main.c
AgeCommit message (Collapse)AuthorFilesLines
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
2022-02-21rtw88: 8822ce: add support for TX/RX 1ss modeChin-Yen Lee1-1/+32
In some case, wifi chip need to be configed to be TX/RX 1ss mode. For this mode, wifi components, such as MAC/BB/RF, need to be specially set, and driver need to send SMPS action frame to inform AP. Signed-off-by: Chin-Yen Lee <timlee@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-2-pkshih@realtek.com
2022-02-10rtw88: recover rates of rate adaptive mechanismChien-Hsun Liao1-23/+44
Some APs like CMW270 only support one phyrate and the function rtw_update_rate_mask could disable that rate. To fix such problem, we restore the rate mask if we find that the rate_mask is empty. Signed-off-by: Chien-Hsun Liao <ben.liao@realtek.com> 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/20220208082427.42433-2-pkshih@realtek.com
2022-01-31rtw88: fix idle mode flow for hw scanPo-Hao Huang1-1/+15
Upon hw scan completion, idle mode is not re-entered. This might increase power consumption under no link mode. Fix this by adding the re-enter flow. We need another work for this since enter_ips waits for c2h_work to finish, which might lead to deadlock if caller is in the same work. Fixes: 10d162b2ed39 ("rtw88: 8822c: add ieee80211_ops::hw_scan") 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/20220121070813.9656-3-pkshih@realtek.com
2021-12-21rtw88: support SAR via kernel common APIZong-Zhe Yang1-0/+22
Register cfg80211_sar_capa with type NL80211_SAR_TYPE_POWER and four frequency ranges for configurations in unit of 0.25 dBm. And handle callback set_sar_specs. Originally, TX power has three main parameters, i.e. power base, power by rate, and power limit. The formula can be simply considered as TX power = power base + min(power by rate, power limit). With the support of SAR which can be treated as another power limit, there is one more parameter for TX power. And the formula will evolve into TX power = power base + min(power by rate, power limit, power sar). Besides, debugfs tx_pwr_tbl is also refined to show SAR information. The following is an example for the difference. Before supporting SAR, ----------------------------------- ... path rate pwr base (byr lmt ) rem A CCK_1M 66(0x42) 78 -12 ( 12 -12) 0 A CCK_2M 66(0x42) 78 -12 ( 8 -12) 0 ... ----------------------------------- After supporting SAR and making some configurations, ----------------------------------- ... path rate pwr base (byr lmt sar ) rem A CCK_1M 62(0x3e) 78 -16 ( 12 -12 -16) 0 A CCK_2M 62(0x3e) 78 -16 ( 8 -12 -16) 0 ... ----------------------------------- Signed-off-by: Zong-Zhe Yang <kevin_yang@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/20211220093656.65312-1-pkshih@realtek.com
2021-12-21rtw88: 8822c: add ieee80211_ops::hw_scanPo-Hao Huang1-0/+63
Declare this function allows us to use customized scanning policy. By doing so we can be more time efficient on each scan. In order to make existing coex mechanism work as usual, firmware notifies driver on each channel switch event, then decide antenna ownership based on the current channel/band. Do note that this new mechanism affects throughput more than the sw_scan we used to have, but the overall average throughput is not affected since each scan take less time. Since the firmware size is limited, we only support probe requests with custom IEs length under 128 bytes for now, if any user space tools requires more than that, we'll introduce related changes afterwards. For backward compatibility, we fallback to sw_scan when using older firmware that does not support this feature. 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/20211221085010.39421-1-pkshih@realtek.com
2021-12-20rtw88: 8822c: update rx settings to prevent potential hw deadlockPo-Hao Huang1-1/+1
These settings enables mac to detect and recover when rx fifo circuit deadlock occurs. Previous version missed this, so we fix it. 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/20211217012708.8623-1-pkshih@realtek.com
2021-12-08rtw88: add debugfs to fix tx rateYan-Hsuan Chuang1-0/+1
It is useful to fix the bit rate of TX packets. For example, if someone is measuring the TX power, or debugging with the issues of the TX throughput on the field. To set the value of fixed rate, one should input corresponding desc rate index (ex, 0x0b for DESC_RATE54M to fix at 54 Mbps). Set a value larger than DESC_RATE_MAX will disable fix rate, so the rate adaptive mechanism can resume to work. Example, To fix rate at MCS 1: echo 0x0d > /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate To not to fix rate: echo 0xff > /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate To know which rate was fixed at: cat /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate Signed-off-by: Yan-Hsuan Chuang <yhchuang@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/20211129020506.6273-1-pkshih@realtek.com
2021-10-05rtw88: refine fw_crash debugfs to show non-zero while triggeringZong-Zhe Yang1-0/+1
The usage of fw_crash debugfs is to write 1 to it to trigger fw crash simulation and to read from it to check the state. When zero is read, it is supposed to mean fw crash/restart process is done. Then, some test plans can be designed for crash/restart. e.g. step 1. trigger fw crash simulation step 2. poll the state until zero is read step 3. check connection by ping test However, in certain connection cases, triggering fw crash simulation will take a while. If the state is queried too early before restart begins processing, it may mistakenly think restart process has been done. If some tests are started at this time, something unexpected might happen due to the follow-up restart process. To avoid that, let fw_crash also show non-zero when a simulation is still triggering. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211001082301.4805-1-pkshih@realtek.com
2021-09-21rtw88: support adaptivity for ETSI/JP DFS regionZong-Zhe Yang1-0/+8
Add Energy Detected CCA (EDCCA) mechanism to detect energy on the channel. And EDCCA support adaptivity mode now. From MIC Ordinance Regulating Radio Equipment article 49.20, ETSI EN-300-328 and EN-301-893, the device should be able to dynamically pause TX activity when energy detected on the air. According to ETSI/JP DFS region, driver will set corresponding threshold and stop TX activity if the detected energy exceeds the threshold. For now, we support it on 8822b and 8822c first. By default, EDCCA mechanism is turned on. For ETSI/JP DFS region, it will turn to adaptivity mode. However, with adaptivity, if environment is too noisy, TX may often be halted. So, a debugfs for EDCCA is added. It can show what EDCCA mode is used currently. And EDCCA mechanism can be turned on/off through the debugfs while debugging. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-4-pkshih@realtek.com
2021-09-21rtw88: add regulatory strategy by chip typeZong-Zhe Yang1-3/+10
Realtek chips can program a specific country domain on efuse to indicate what is the expected rtw_regulatory. For chips with a programmed country domain, we set REGULATORY_STRICT_REG to tell stack to consider follow-up regulatory_hint() as the superset of our regulatory rule. Besides, on driver side, only the request via NL80211_REGDOM_SET_BY_DRIVER, which matches programmed country domain, will be handled to keep rtw_regulatory unchanged. For worldwide roaming chips, i.e. ones without a specific programmed country domain, system of distro can set expected regulatory via NL80211_REGDOM_SET_BY_USER. With setting from it, rtw_regulatory will handle the requests only via NL80211_REGDOM_SET_BY_USER to follow setting from system of distro. REGULATORY_COUNTRY_IE_IGNORE will then be set to tell stack to ignore country IE for us. The restrictions mentioned above will remain until 00, i.e. worldwide, is set via NL80211_REGDOM_SET_BY_USER. On the other hand, for worldwide roamin chips, if there is no specific regulatory set via NL80211_REGDOM_SET_BY_USER, requests from all regulatory notifications will be handled by rtw_regulatory. And REGULATORY_COUNTRY_IE_IGNORE won't be set. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-3-pkshih@realtek.com
2021-08-21rtw88: 8822c: add tx stbc support under HT modePo-Hao Huang1-0/+2
Enabling this improves tx performance for long distance transmission. We used to enable stbc by the rx stbc cap of the associated station. But rx cap will be masked out in ieee80211_ht_cap_ie_to_sta_ht_cap if we do not declare tx stbc. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210713104524.47101-2-pkshih@realtek.com
2021-06-24rtw88: fix c2h memory leakPo-Hao Huang1-0/+1
Fix erroneous code that leads to unreferenced objects. During H2C operations, some functions returned without freeing the memory that only the function have access to. Release these objects when they're no longer needed to avoid potentially memory leaks. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210624023459.10294-1-pkshih@realtek.com
2021-06-22rtw88: dump FW crash via devcoredumpZong-Zhe Yang1-51/+119
Use device coredump framework instead of print_hex_dump to support FW crash dump. Pass data to the framework if preparing and dumping are successful. The framework will take the ownership of the data. The data will be freed after the framework determines its lifetime is over. A new coredump will not work if the previous one still exists. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210528032901.12927-2-pkshih@realtek.com
2021-06-22rtw88: notify fw when driver in scan-period to avoid potential problemChin-Yen Lee1-0/+17
It is found that driver scan could be affected by dynamic mechanism of firmware, so we notify firmware to stop it in the scan period. Another, firmware will detect the background noise and report to driver for further use. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210514075517.14216-3-pkshih@realtek.com
2021-06-22rtw88: add rtw_fw_feature_check apiChin-Yen Lee1-2/+2
add api to check if a certain feature is supported. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210514075517.14216-2-pkshih@realtek.com
2021-06-22rtw88: add beacon filter supportPo-Hao Huang1-1/+3
Adding this supports beacon filter and CQM. Let firmware perform connection quality monitor and beacon processing. This make host CPU wakeup less under power save mode. To make mechanisms work as usual, fw will notify driver events such as signal change and beacon loss. This feature needs firmware 9.9.8 or newer to support it, and driver is compatible with older firmware. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210426013252.5665-1-pkshih@realtek.com
2021-03-15rtw88: 8822c: support FW crash dump when FW crashZong-Zhe Yang1-14/+86
Although FW crash logs are already supported for dumping in driver, the logs may not be sufficient to analyze field issues. To improve this part, we add a support to dump FW memory. When driver receives FW crash notifications, driver uses DDMA, which is a HW ability, to copy specified FW memory to FW fifo. Driver can then dump these information from FW fifo. With this support, not only FW crash log but also specified FW memory will be dumped while FW crash. Besides, specified registers are also dumped. This feature is implemeted on 8822C first due to difference of FW layouts between ICs. In addition, we add a debugfs to trigger FW crash. It can simulate the process of crash, dump and reset. Through it, we can also check if a reset is ongoing. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210309060121.9099-1-pkshih@realtek.com
2021-03-15rtw88: remove unnecessary variablewengjianfeng1-2/+1
The variable ret is defined at the beginning and initialized to 0 until the function returns ret, and the variable ret is not reassigned.Therefore, we do not need to define the variable ret, just return 0 directly at the end of the function. Signed-off-by: wengjianfeng <wengjianfeng@yulong.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210223075438.13676-1-samirweng1979@163.com
2021-03-15rtw88: coex: add power off settingPing-Ke Shih1-0/+1
Clear WL/BT on/off bit in scoreboard register that is used to exchange WL/BT status. Since the status is preserved after warm reboot, we must clear it when WL is going to down. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210219054140.7835-1-pkshih@realtek.com
2021-02-12rtw88: replace tx tasklet with work queuePo-Hao Huang1-2/+3
Replace tasklet so we can do tx scheduling in parallel. Since throughput is delay-sensitive in most cases, we allocate a dedicated, high priority wq for our needs. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210209070755.23019-5-pkshih@realtek.com
2021-02-12rtw88: add dynamic rrsr configurationPo-Hao Huang1-0/+3
Register rrsr determines the response rate we send. In field tests, using rate higher than current tx rate could lead to difficulty for the receiving end to receive management/control frames. Calculate current modulation level by tx rate then cross out rate higher than those. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210209070755.23019-2-pkshih@realtek.com
2021-02-08rtw88: 8821c: support RFE type2 wifi NICGuo-Feng Fan1-0/+2
RFE type2 is a new NIC which has one RF antenna shares with BT. Update phy parameter to verstion V57 to allow initial procedure to load extra AGC table for sharing antenna NIC. Signed-off-by: Guo-Feng Fan <vincent_fann@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210202055012.8296-4-pkshih@realtek.com
2021-01-14rtw88: Delete useless kfree codeZheng Yongjun1-1/+0
The parameter of kfree function is NULL, so kfree code is useless, delete it. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201216130442.13869-1-zhengyongjun3@huawei.com
2020-12-07rtw88: declare hw supports ch 144Zong-Zhe Yang1-0/+1
When driver was developed, FCC regulation didn't enable channel 144 and there was no demand for channel 144 at that time. Although HW actually supports channel 144, driver didn't announce channel 144. Therefore, channel 144 (20 MHz), channel 142 (40 MHz) and channel 138 (80 MHz) couldn't be used. Today, channel 144 has been enabled by regulations and is gradually being supported. With test requirements, we declare hw supports channel 144. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201204013823.3729-1-pkshih@realtek.com
2020-12-02rtw88: coex: add function to avoid cck lockChing-Te Ku1-0/+5
Some AP will not follow the power save request, or it cannot stop transmission until its queue is empty. It may bring the decreasing of data rate. WLAN firmware will count is the AP still leaked packet after power save handshake was done or not to enable WLAN slot extend mechanism. The extend WLAN slot mechanism will extend the WLAN slot after power save handshake, 5 ms per times, maximum is 5 times to received the leaked packet to avoid the rate lower down. And if the transmission was already locked at CCK rate. The extended WLAN slot can also increase the opportunity that we can received the CCK's long packet and be released from CCK rate. While BT multi-link status was finished, there is possible that it still has some packet remained for seconds. Add a timer to remain the multi-link mechanism to protect WLAN Rx. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201126021059.11981-8-pkshih@realtek.com
2020-11-10rtw88: coex: change the parameter for A2DP when WLAN connectingChing-Te Ku1-0/+2
The original mechanism may cause A2DP glitch during WiFi connecting AP. Because the original TDMA may decrease too much A2DP slot. This patch add a timer and variable to let the case A2DP + WL_Connecting performed more well. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201109085909.9143-9-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-14 01:42:41 +0000