| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously we only disable invalid reports for 52A, since we plan to
support more ICs in the future, enable settings for those as well.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-12-pkshih@realtek.com
|
|
TX BD (TX ring index) and TX WD (WiFi descriptor buffer) are freed
asynchronously. With burst packets, we free TX WD, but the corresponding
TX BD couldn't be freed yet. Then, TX can possibly get stuck due to no
more TX BD.
To avoid this, ignore reclaiming TX BD only if TX WD is no free space,
because at this moment TX BD must have some spaces. Otherwise, we reclaim
TX BD to resolve TX stuck issue.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-11-pkshih@realtek.com
|
|
In low power mode, regular IO is power off, so we don't schedule napi to
poll RX and TX completion. Therefore, calling ieee80211_rx_napi() with
napi instance causes long RX latency. To fix this, use NULL as argument,
and then it can use netif_receive_skb_list() to receive.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-10-pkshih@realtek.com
|
|
Somehow, firmware could report invalid TX rate, and we consider the
invalid rate as 0 that will make a wrong decision. So, drop invalid
reports, and also suppress the warning message.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-9-pkshih@realtek.com
|
|
Some warning messages could bother users. With proper handling, these
situations don't really affect usage, but we still need to keep monitor
these messages. If they happen frequently, we must review driver or
hardware design to clarify.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-8-pkshih@realtek.com
|
|
To improve VO throughput, we enable VO TX AMPDU.
We measure the latency of enable or disable VO TX AMPDU. The experimental
results show that the difference between the two is insignificant only
300µs, so the little impact can be ignored for user experience.
Moreover, we found some APs will have a group key handshake timeout issue
when the EAPOL's TID is already setup BA session. Therefore, when
transmitting EAPOL, if EAPOL's TID BA session is already setup, we need
to delete it.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-7-pkshih@realtek.com
|
|
The potential TX stuck occurs when there are lots of packets to be
transmitted and the boundary of the tx_resource is hit. Add this
patch to avoid the TX stuck when burst traffic.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-6-pkshih@realtek.com
|
|
Since we can allocate MAC ID, BSSID and address CAM to TDLS peer, declare
we can support TDLS now.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-5-pkshih@realtek.com
|
|
In STA mode, if peer is TDLS. Allocate a BSSID CAM entry with peer's
address to match address properly, and then hardware can ACK peer's
packets and receive packets to driver.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-4-pkshih@realtek.com
|
|
Normally, we allocate a BSSID CAM to a vif. By hardware design, we must
allocate a BSSID CAM to each TDLS peer, so separate BSSID CAM operations
that will be used by later patches.
This patch doesn't change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-3-pkshih@realtek.com
|
|
Normally, we only allocate an address CAM and single one MAC ID to AP in
STA mode. To support TDLS, we handle TDLS peers like AP handles stations.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-2-pkshih@realtek.com
|
|
Pass the link id through to the get_beacon and return
the beacon for a specific link id.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In start_ap and stop_ap mac80211 callbacks pass the link_id
to the drivers.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
Split the bss_info_changed method to vif_cfg_changed and
link_info_changed, with the latter getting a link ID.
Also change the 'changed' parameter to u64 already, we
know we need that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
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>
|
|
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>
|
|
We would like to make chip_info table const, but 8821c uses one field as
a variable, and causes core dump. To fix this, move the field to another
struct that can be read and written.
BUG: unable to handle page fault for address: ffffffffc09f52f4
PGD 5b5215067 P4D 5b5215067 PUD 5b5217067 PMD 111f61067 PTE 8000000111e07161
Oops: 0003 [#1] PREEMPT SMP NOPTI
CPU: 6 PID: 436 Comm: NetworkManager Not tainted 5.18.0-rc7-debug-01822-g89d8f53ff6e7 #1 5cac31ca93432e53341863abfb3332fd98b144da
Hardware name: HP HP Desktop M01-F1xxx/87D6, BIOS F.12 12/17/2020
RIP: 0010:rtw8821c_phy_set_param+0x262/0x380 [rtw88_8821c]
Code: e8 53 f3 c0 d6 48 8b 43 10 4c 8b 63 38 be 24 0a 00 00 48 89 df 48
8b 40 68 e8 3a f3 c0 d6 89 e9 be 28 0a 00 00 48 89 df d3 e8 <41> 89 84
24 54 01 00 00 48 8b 43 10 4c 8b 63 38 48 8b 40 68 e8 15
RSP: 0018:ffffb08c417cb6f0 EFLAGS: 00010286
RAX: 0000000064b80c1c RBX: ffff93d15a0120e0 RCX: 0000000000000000
RDX: 0000000034028211 RSI: 0000000000000a28 RDI: ffff93d15a0120e0
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000006 R12: ffffffffc09f51a0
R13: ffff93d15a0156d0 R14: 0000000000000000 R15: 0000000000000001
FS: 00007f4e9b73d1c0(0000) GS:ffff93d83ab80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffc09f52f4 CR3: 0000000103b9e000 CR4: 0000000000350ee0
Call Trace:
<TASK>
rtw_core_start+0xbd/0x190 [rtw88_core de79d6bdfd083d102030858972032e5706726279]
rtw_ops_start+0x26/0x40 [rtw88_core de79d6bdfd083d102030858972032e5706726279]
drv_start+0x42/0x100 [mac80211 21e803d0ad10691f64c6c81ecc24c0c6c36e5d58]
ieee80211_do_open+0x2fb/0x900 [mac80211 21e803d0ad10691f64c6c81ecc24c0c6c36e5d58]
ieee80211_open+0x67/0x80 [mac80211 21e803d0ad10691f64c6c81ecc24c0c6c36e5d58]
__dev_open+0xdd/0x180
[...]
Fixes: 89d8f53ff6e7 ("wifi: rtw88: Fix Sparse warning for rtw8821c_hw_spec")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220608020312.9663-1-pkshih@realtek.com
|
|
Add an new state, RTW89_PHY_DCFO_STATE_HOLD, to keep CFO acceleration
after CFO_PERIOD_CNT if the traffic is UL-OFDMA, which is calculated
based on RX trigger frame counter.
Signed-off-by: Eric Huang <echuang@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/20220608113224.11193-4-pkshih@realtek.com
|
|
Adding this allows us to maintain trigger frame statistics, which is
required for our CFO tracking decisions.
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/20220608113224.11193-3-pkshih@realtek.com
|
|
The BSSID mask of H2C is used to match BSSID of receiving packets.
Normally, we set six bits BSSID mask to exactly match BSSID of packets
sent by target AP. After we support multiple BSSID, it could connect a
nontransmitted BSSID, so we can only match first five bytes of BSSID.
That means we could possibly receive other AP's packets if only the last
byte of BSSID is different from target AP.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220530112743.106857-1-pkshih@realtek.com
|
|
Use %*ph format to print small buffer as hex string.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220603125648.46873-1-andriy.shevchenko@linux.intel.com
|
|
If the copy_from_user() fails or the user gives invalid date then the
correct thing to do is to return a negative error code. (Currently it
returns success).
I made a copy additional related cleanups:
1) There is no need to check "buffer" for NULL. That's handled by
copy_from_user().
2) The "h2c_len" variable cannot be negative because it is unsigned
and because sscanf() does not return negative error codes.
Fixes: 610247f46feb ("rtlwifi: Improve debugging by using debugfs")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/YoOLnDkHgVltyXK7@kili
|
|
Sparse lists the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8821c.c
drivers/net/wireless/realtek/rtw88/rtw8821c.c:1880:22: warning: symbol 'rtw8821c_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8821c_hw_spec
occurs in rtw8821ce.h, which is not included in rtw8821c.h. That line is
moved, and the now empty file rtw8821ce.h is deleted.
Symbol 'rtw8821c_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153716.20450-1-Larry.Finger@lwfinger.net
|
|
Sparse lists the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8723d.c
drivers/net/wireless/realtek/rtw88/rtw8723d.c:2704:22: warning: symbol 'rtw8723d_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8723d_hw_spec
occurs in rtw8723de.h, which is not included in rtw8723d.h. That line is
moved, and the now empty file rtw8723de.h is deleted.
Symbol 'rtw8723d_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-4-Larry.Finger@lwfinger.net
|
|
Sparse reports the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8822c.c
drivers/net/wireless/realtek/rtw88/rtw8822c.c:5313:22: warning: symbol 'rtw8822c_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8822c_hw_spec
occurs in rtw8822ce.h, which is not included in rtw8822c.h. That line is
moved, and the now empty file rtw8822ce.h is deleted.
Symbol 'rtw8822c_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-3-Larry.Finger@lwfinger.net
|
|
Sparse lists the following for rtw88:
CHECK drivers/net/wireless/realtek/rtw88/rtw8822b.c
drivers/net/wireless/realtek/rtw88/rtw8822b.c:2500:22: warning: symbol 'rtw8822b_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8822b_hw_spec
occurs in rtw8822be.h, which is not included in rtw8822b.h. That line is
moved, and the now empty file rtw8822be.h is deleted.
Symbol 'rtw8822b_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-2-Larry.Finger@lwfinger.net
|
|
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
|
|
Since SAR is more expected to follow U-NII bands to plan subbands,
division of 6GHz band is quite different from defined enum of subbands
which is used by PHY in most cases. It's hard and painful if we want to
keep using the same enum on SAR. So, we introduce another enum for SAR
subbands and adjust SAR flow to use it.
Besides, since 6GHz SAR subbands won't be divided with edge alignment,
some cases will span two SAR subbands. For these cases, we describe them
within an array of rtw89_sar_span and take the smaller one between SAR
settings of the two subbands.
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/20220520071731.38563-6-pkshih@realtek.com
|
|
RX DCK is receiver DC calibration. To keep good RF performance, do this
calibration again if the delta of thermal value from the last calibration
is more than 8.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220520071731.38563-5-pkshih@realtek.com
|
|
This watchdog timeout status bit indicates hardware gets wrong, so run SER
L2 flow that calls mac80211 to restart hardware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220520071731.38563-4-pkshih@realtek.com
|
|
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/20220520071731.38563-3-pkshih@realtek.com
|
|
Previously channel maintained by driver could be different from the
ones hardware actually is. Restore these variables back to prevent
unexpected behavior.
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/20220520071731.38563-2-pkshih@realtek.com
|
|
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
|
|
The .value is a two-dim array, not a pointer.
struct iqk_matrix_regs {
bool iqk_done;
long value[1][IQK_MATRIX_REG_NUM];
};
Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The design of INT indicator register (R_AX_PCIE_HIMR00_V1) is to reduce IO
during frequent interrupts, because it can stop chip sending interrupt to
host if we just set this indicator to 0, not all IMR(s). This indicator
register looks like a root interrupt controller of wifi chip.
However, we can't set all other IMR(s) to 0 during we are running on
interrupt service routine, or the indicator register can't reflect the
status of certain interrupt happened during this period, and then miss
some interrupts especially SER interrupt events.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220516005215.5878-7-pkshih@realtek.com
|
|
Before 6 GHz band was supported, i.e. only 2 GHz and 5 GHz, they were the
same from the numerical point of view. However, after 6 GHz band support,
we need to do this conversion logically.
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/20220516005215.5878-6-pkshih@realtek.com
|
|
Update notes:
update the following to HALRF_027_00_052
TX power by rate table
TX power limit table
TX power limit RU table
TX shape table doesn't seem to be changed on HALRF_027_00_052
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/20220516005215.5878-5-pkshih@realtek.com
|
|
Somehow, hardware reports incorrect mac_id and pollute memory. Check index
before we access the array.
UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23
index 188 is out of range for type 's32 [64]'
CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE
Call Trace:
<IRQ>
show_stack+0x52/0x58
dump_stack_lvl+0x4c/0x63
dump_stack+0x10/0x12
ubsan_epilogue+0x9/0x45
__ubsan_handle_out_of_bounds.cold+0x44/0x49
? __alloc_skb+0x92/0x1d0
rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core]
rtw89_core_rx+0x261/0x871 [rtw89_core]
? __alloc_skb+0xee/0x1d0
rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci]
__napi_poll+0x33/0x1a0
net_rx_action+0x126/0x260
? __queue_work+0x217/0x4c0
__do_softirq+0xd9/0x315
? disable_irq_nosync+0x10/0x10
do_softirq.part.0+0x6d/0x90
</IRQ>
<TASK>
__local_bh_enable_ip+0x62/0x70
rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci]
irq_thread_fn+0x28/0x60
irq_thread+0xc8/0x190
? irq_thread_fn+0x60/0x60
kthread+0x16b/0x190
? irq_thread_check_affinity+0xe0/0xe0
? set_kthread_struct+0x50/0x50
ret_from_fork+0x22/0x30
</TASK>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220516005215.5878-4-pkshih@realtek.com
|
|
To make user space can set TX antenna via iw command. Then, we can diagnose
antenna is connected properly or not, and measure TX power in single path.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220516005215.5878-3-pkshih@realtek.com
|
|
When peer's NSS, rate or bandwidth is changed, we update RA(rate adaptive)
mask to ensure transmitting packets properly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220516005215.5878-2-pkshih@realtek.com
|
|
This memory allocation failure can be triggered by fault injection or
high pressure testing, resulting a WARN.
Fix this by replacing WARN with pr_warn.
Reported-by: syzkaller <syzkaller@googlegroups.com>
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220511014453.1621366-1-dzm91@hust.edu.cn
|
|
BSSID CAM is a kind of CAM that is used to determine if we receive a packet
or not. Add an entry to assist in debugging.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220506120216.58567-6-pkshih@realtek.com
|
|
Dump new region 0x3000 to 0x33ff to help debug.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220506120216.58567-5-pkshih@realtek.com
|
|
EDCCA signal can block transmitting in certain situation, so ignore this
signal and use others to decide transmitting time.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220506120216.58567-4-pkshih@realtek.com
|
|
Set proper setting according to RX quota, and then it doesn't break buffer
due to size of received packet exceeding buffer size.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220506120216.58567-3-pkshih@realtek.com
|
|
Modify NBI and PD boost settings according to different primary channels.
This setting can decrease the false alarm induced by DC.
Signed-off-by: Hsuan Hung <hsuan8331@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/20220506120216.58567-2-pkshih@realtek.com
|
|
Fine tune algorithm of adaptivity sensitivity to avoid disconnecting
from AP suddenly in field.
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/20220506235045.4669-1-pkshih@realtek.com
|
|
This initial vesion is usable now. It can support STA, AP and monitor
modes, so we can add 8852ce to Kconfig and Makefile.
We are still working on some features, such as deep power save, and BT
coexistence. But, this version still can have a good WiFi-only performance
already, and will continue to fine tune power consumption.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220503120001.79272-9-pkshih@realtek.com
|
|
To fix the compiler warning of clang with i386 config, but not complain
by gcc:
__write_ctrl(R_AX_PWR_RATE_CTRL, B_AX_FORCE_PWR_BY_RATE_VALUE_MASK,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/rtw8852c.c:2621:13: note: expanded from macro '__write_ctrl'
u32 _wrt = FIELD_PREP(__msk, _val); \
^~~~~~~~~~~~~~~~~~~~~~~
include/linux/bitfield.h:114:3: note: expanded from macro 'FIELD_PREP'
__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/bitfield.h:71:53: note: expanded from macro '__BF_FIELD_CHECK'
BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
include/linux/compiler_types.h:352:22: note: expanded from macro 'compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/compiler_types.h:340:23: note: expanded from macro '_compiletime_assert'
__compiletime_assert(condition, msg, prefix, suffix)
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/compiler_types.h:332:9: note: expanded from macro '__compiletime_assert'
if (!(condition)) \
^~~~~~~~~
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220503120001.79272-8-pkshih@realtek.com
|
Po-Hao Huang
Ping-Ke Shih
Kuan-Chung Chen
Shaul Triebitz
Johannes Berg
Jakub Kicinski
Eric Huang
Andy Shevchenko
Dan Carpenter
Larry Finger
Zong-Zhe Yang
Dongliang Mu
Hsuan Hung
Chin-Yen Lee