The linux-next integration testing tree https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=akpm 2022-06-28T05:41:12+00:00 2022-06-28T05:41:12+00:00 Stephen Rothwell sfr@canb.auug.org.au 2022-06-28T05:41:12+00:00 urn:sha1:a3eea72ac05e12c24d3dbfe2dbeef7cffc5bf306 2022-06-28T01:09:19+00:00 Stephen Rothwell sfr@canb.auug.org.au 2022-06-28T01:09:19+00:00 urn:sha1:afe968a08b294a91fa99c839d4db76c79fbd9111 2022-06-28T01:09:16+00:00 Stephen Rothwell sfr@canb.auug.org.au 2022-06-28T01:09:16+00:00 urn:sha1:c95333b2ff8c3325df74d1eb36c3c797c9096dc0 # Conflicts: # arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts 2022-06-27T22:56:31+00:00 Stephen Rothwell sfr@canb.auug.org.au 2022-06-27T22:56:31+00:00 urn:sha1:a15a8e7f4e9d849531b250ea1978b42b231d46e9 2022-06-21T06:16:39+00:00 Ping-Ke Shih pkshih@realtek.com 2022-06-13T06:51:44+00:00 urn:sha1:683a4647a7a3044868cfdc14c117525091b9fa0c The DPK is a kind of RF calibration whose algorithm is to fine tune parameters and calibrate, and check the result. If the result isn't good enough, it could adjust parameters and try again. This issue is to read and show the result, but it could be a negative calibration result that causes divisor 0 and core dump. So, fix it by phy_div() that does division only if divisor isn't zero; otherwise, zero is adopted. divide error: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1 <HASH:d024 28> RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core] RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 00000000000180fc RDI: ffffa141d01023c0 RBP: ffffa9bb412a76a0 R08: 0000000000001319 R09: 00000000ffffff92 R10: ffffffffc0292de3 R11: ffffffffc00d2f51 R12: 0000000000000000 R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638 FS: 00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000013e8e010 CR3: 0000000110d2c000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: rtw89_core_sta_add+0x95/0x9c [rtw89_core <HASH:d239 29>] rtw89_ops_sta_state+0x5d/0x108 [rtw89_core <HASH:d239 29>] drv_sta_state+0x115/0x66f [mac80211 <HASH:81fe 30>] sta_info_insert_rcu+0x45c/0x713 [mac80211 <HASH:81fe 30>] sta_info_insert+0xf/0x1b [mac80211 <HASH:81fe 30>] ieee80211_prep_connection+0x9d6/0xb0c [mac80211 <HASH:81fe 30>] ieee80211_mgd_auth+0x2aa/0x352 [mac80211 <HASH:81fe 30>] cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 <HASH:00cd 31>] nl80211_authenticate+0x2e5/0x306 [cfg80211 <HASH:00cd 31>] genl_rcv_msg+0x371/0x3a1 ? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 <HASH:00cd 31>] ? genl_rcv+0x36/0x36 netlink_rcv_skb+0x8a/0xf9 genl_rcv+0x28/0x36 netlink_unicast+0x27b/0x3a0 netlink_sendmsg+0x2aa/0x469 sock_sendmsg_nosec+0x49/0x4d ____sys_sendmsg+0xe5/0x213 __sys_sendmsg+0xec/0x157 ? syscall_enter_from_user_mode+0xd7/0x116 do_syscall_64+0x43/0x55 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fa99f6e689b Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220613065144.15647-1-pkshih@realtek.com 2022-06-21T06:15:48+00:00 Po-Hao Huang phhuang@realtek.com 2022-06-10T07:26:10+00:00 urn:sha1:47324ab67af7f8e128688c13bd05a23c496bf661 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 2022-06-21T06:15:48+00:00 Ping-Ke Shih pkshih@realtek.com 2022-06-10T07:26:09+00:00 urn:sha1:37c6abc374d1f1e0dd2e9fcc5a789886a63c894a 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 2022-06-21T06:15:48+00:00 Ping-Ke Shih pkshih@realtek.com 2022-06-10T07:26:08+00:00 urn:sha1:c4756d5de72e549fdaa32a1fab12ae776fca5be7 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 2022-06-21T06:15:48+00:00 Ping-Ke Shih pkshih@realtek.com 2022-06-10T07:26:07+00:00 urn:sha1:9a3a593cba9a6743022ab742c01b06280e8a288a 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 2022-06-21T06:15:47+00:00 Ping-Ke Shih pkshih@realtek.com 2022-06-10T07:26:06+00:00 urn:sha1:ad663693c1bf148bdc84a29bcebfe9eb4dc812c4 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