Remove extend 5 ms related operation at WLAN media status notify.
The mechanism should be enable only while DUT connect to a AP that it
doesn't follow our power save control or its rate is decreasing unusually
sensitive. So we extend a extra slot to save the transmission rate.
The original logic will always extend WLAN slot.
It will lead to BT slot always decrease 5 ms.
Remove write scoreboard action at WLAN media status notify.
It has already done in WLAN info notify.
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/20201112031430.4846-11-pkshih@realtek.com
CCK PD can reduce the number of false alarm of the CCK rates.
It dynamically adjusts the power threshold and CS ratio.
The values are compared to the values of the previous level, if
the level is changed, set new values of power threshold and CS
ratio.
Implement rtw_chip_ops::cck_pd_set() for 8723d.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201109090123.9254-1-pkshih@realtek.com
Life time related setting is related to WLAN active port number,
not its mode. The original setting may cause poor WLAN performance.
In most case, WLAN TX limitation is helpful for BT in coexistence
scenario, especially for A2DP quality.
So this is necessary to fix the setting and constraint it.
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-12-pkshih@realtek.com
Add counter to count BT info C2H command for debug usage.
It could present the C2H channel situation.
Fix BT IQK state decision condition for counting.
The original condition is wrong, it would cause coexistence mechanism
going to the wrong strategy.
New format supports getting TDMA parameter from WL firmware, since
coexistence needs current TDMA parameter to decide strategy.
Remove unnecessary operations about scoreboard, it is not a must for
current version.
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-8-pkshih@realtek.com
The interrupt handling of the RS911x is particularly heavy. For each RX
packet, the card does three SDIO transactions, one to read interrupt
status register, one to RX buffer length, one to read the RX packet(s).
This translates to ~330 uS per one cycle of interrupt handler. In case
there is more incoming traffic, this will be more.
The drivers/mmc/core/sdio_irq.c has the following comment, quote "Just
like traditional hard IRQ handlers, we expect SDIO IRQ handlers to be
quick and to the point, so that the holding of the host lock does not
cover too much work that doesn't require that lock to be held."
The RS911x interrupt handler does not fit that. This patch therefore
changes it such that the entire IRQ handler is moved to the RX thread
instead, and the interrupt handler only wakes the RX thread.
This is OK, because the interrupt handler only does things which can
also be done in the RX thread, that is, it checks for firmware loading
error(s), it checks buffer status, it checks whether a packet arrived
and if so, reads out the packet and passes it to network stack.
Moreover, this change permits removal of a code which allocated an
skbuff only to get 4-byte-aligned buffer, read up to 8kiB of data
into the skbuff, queue this skbuff into local private queue, then in
RX thread, this buffer is dequeued, the data in the skbuff as passed
to the RSI driver core, and the skbuff is deallocated. All this is
replaced by directly calling the RSI driver core with local buffer.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Angus Ainslie <angus@akkea.ca>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Martin Kepplinger <martink@posteo.de>
Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Cc: Siva Rebbagondla <siva8118@gmail.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Tested-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201103180941.443528-1-marex@denx.de
If a reset is performed, but even the reset fails for some reasons (e.g.,
on Surface devices, the fw reset requires another quirks),
cancel_work_sync() hangs in mwifiex_cleanup_pcie().
# firmware went into a bad state
[...]
[ 1608.281690] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex...
[ 1608.282724] mwifiex_pcie 0000:03:00.0: rx_pending=0, tx_pending=1, cmd_pending=0
[ 1608.292400] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
[ 1608.292405] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
# reset performed after firmware went into a bad state
[ 1609.394320] mwifiex_pcie 0000:03:00.0: WLAN FW already running! Skip FW dnld
[ 1609.394335] mwifiex_pcie 0000:03:00.0: WLAN FW is active
# but even the reset failed
[ 1619.499049] mwifiex_pcie 0000:03:00.0: mwifiex_cmd_timeout_func: Timeout cmd id = 0xfa, act = 0xe000
[ 1619.499094] mwifiex_pcie 0000:03:00.0: num_data_h2c_failure = 0
[ 1619.499103] mwifiex_pcie 0000:03:00.0: num_cmd_h2c_failure = 0
[ 1619.499110] mwifiex_pcie 0000:03:00.0: is_cmd_timedout = 1
[ 1619.499117] mwifiex_pcie 0000:03:00.0: num_tx_timeout = 0
[ 1619.499124] mwifiex_pcie 0000:03:00.0: last_cmd_index = 0
[ 1619.499133] mwifiex_pcie 0000:03:00.0: last_cmd_id: fa 00 07 01 07 01 07 01 07 01
[ 1619.499140] mwifiex_pcie 0000:03:00.0: last_cmd_act: 00 e0 00 00 00 00 00 00 00 00
[ 1619.499147] mwifiex_pcie 0000:03:00.0: last_cmd_resp_index = 3
[ 1619.499155] mwifiex_pcie 0000:03:00.0: last_cmd_resp_id: 07 81 07 81 07 81 07 81 07 81
[ 1619.499162] mwifiex_pcie 0000:03:00.0: last_event_index = 2
[ 1619.499169] mwifiex_pcie 0000:03:00.0: last_event: 58 00 58 00 58 00 58 00 58 00
[ 1619.499177] mwifiex_pcie 0000:03:00.0: data_sent=0 cmd_sent=1
[ 1619.499185] mwifiex_pcie 0000:03:00.0: ps_mode=0 ps_state=0
[ 1619.499215] mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device
# mwifiex_pcie_work hang happening
[ 1823.233923] INFO: task kworker/3:1:44 blocked for more than 122 seconds.
[ 1823.233932] Tainted: G WC OE 5.10.0-rc1-1-mainline #1
[ 1823.233935] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1823.233940] task:kworker/3:1 state:D stack: 0 pid: 44 ppid: 2 flags:0x00004000
[ 1823.233960] Workqueue: events mwifiex_pcie_work [mwifiex_pcie]
[ 1823.233965] Call Trace:
[ 1823.233981] __schedule+0x292/0x820
[ 1823.233990] schedule+0x45/0xe0
[ 1823.233995] schedule_timeout+0x11c/0x160
[ 1823.234003] wait_for_completion+0x9e/0x100
[ 1823.234012] __flush_work.isra.0+0x156/0x210
[ 1823.234018] ? flush_workqueue_prep_pwqs+0x130/0x130
[ 1823.234026] __cancel_work_timer+0x11e/0x1a0
[ 1823.234035] mwifiex_cleanup_pcie+0x28/0xd0 [mwifiex_pcie]
[ 1823.234049] mwifiex_free_adapter+0x24/0xe0 [mwifiex]
[ 1823.234060] _mwifiex_fw_dpc+0x294/0x560 [mwifiex]
[ 1823.234074] mwifiex_reinit_sw+0x15d/0x300 [mwifiex]
[ 1823.234080] mwifiex_pcie_reset_done+0x50/0x80 [mwifiex_pcie]
[ 1823.234087] pci_try_reset_function+0x5c/0x90
[ 1823.234094] process_one_work+0x1d6/0x3a0
[ 1823.234100] worker_thread+0x4d/0x3d0
[ 1823.234107] ? rescuer_thread+0x410/0x410
[ 1823.234112] kthread+0x142/0x160
[ 1823.234117] ? __kthread_bind_mask+0x60/0x60
[ 1823.234124] ret_from_fork+0x22/0x30
[...]
This is a deadlock caused by calling cancel_work_sync() in
mwifiex_cleanup_pcie():
- Device resets are done via mwifiex_pcie_card_reset()
- which schedules card->work to call mwifiex_pcie_card_reset_work()
- which calls pci_try_reset_function().
- This leads to mwifiex_pcie_reset_done() be called on the same workqueue,
which in turn calls
- mwifiex_reinit_sw() and that calls
- _mwifiex_fw_dpc().
The problem is now that _mwifiex_fw_dpc() calls mwifiex_free_adapter()
in case firmware initialization fails. That ends up calling
mwifiex_cleanup_pcie().
Note that all those calls are still running on the workqueue. So when
mwifiex_cleanup_pcie() now calls cancel_work_sync(), it's really waiting
on itself to complete, causing a deadlock.
This commit fixes the deadlock by skipping cancel_work_sync() on a reset
failure path.
After this commit, when reset fails, the following output is
expected to be shown:
kernel: mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device
kernel: mwifiex: Failed to bring up adapter: -5
kernel: mwifiex_pcie 0000:03:00.0: reinit failed: -5
To reproduce this issue, for example, try putting the root port of wifi
into D3 (replace "00:1d.3" with your setup).
# put into D3 (root port)
sudo setpci -v -s 00:1d.3 CAP_PM+4.b=0b
Cc: Maximilian Luz <luzmaximilian@gmail.com>
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201028142346.18355-1-kitakar@gmail.com
The functions mwifiex_shutdown_sw() and mwifiex_reinit_sw() can be used
for more general purposes than the PCIe function level reset. Also, these
are even not PCIe-specific.
So, let's update the comments at the top of each function accordingly.
Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201028142110.18144-3-kitakar@gmail.com
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c: In function ‘btc8821a2ant_action_bt_inquiry’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:1451:40: warning: variable ‘bt_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:1451:22: warning: variable ‘wifi_rssi_state1’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:1451:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c: In function ‘btc8821a2ant_action_wifi_idle_process’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:1519:40: warning: variable ‘bt_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:1519:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c: In function ‘btc8821a2ant_action_pan_hs’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2990:22: warning: variable ‘wifi_rssi_state1’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c: In function ‘btc8821a2ant_action_hid_a2dp’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3277:22: warning: variable ‘wifi_rssi_state1’ set but not used [-Wunused-but-set-variable]
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201102112410.1049272-31-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_wifi_idle_process’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:1631:40: warning: variable ‘bt_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:1631:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_sco’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2767:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_hid’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2810:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_a2dp’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2855:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_a2dp_pan_hs’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2929:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_pan_edr’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:2976:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_pan_hs’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:3028:22: warning: variable ‘wifi_rssi_state1’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:3028:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_pan_edr_a2dp’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:3066:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_pan_edr_hid’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:3121:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_hid_a2dp_pan_edr’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:3185:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c: In function ‘btc8723b2ant_action_hid_a2dp’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:3244:5: warning: variable ‘wifi_rssi_state’ set but not used [-Wunused-but-set-variable]
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201102112410.1049272-26-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
from drivers/net/wireless/intersil/prism54/isl_ioctl.c:22:
inlined from ‘prism54_get_name’ at drivers/net/wireless/intersil/prism54/isl_ioctl.c:283:2:
drivers/net/wireless/intersil/prism54/isl_ioctl.c:68: warning: Function parameter or member 'priv' not described in 'prism54_mib_mode_helper'
drivers/net/wireless/intersil/prism54/isl_ioctl.c:68: warning: Excess function parameter 'mib' description in 'prism54_mib_mode_helper'
drivers/net/wireless/intersil/prism54/isl_ioctl.c:127: warning: Function parameter or member 'priv' not described in 'prism54_mib_init'
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Aurelien Alleaume <slts@free.fr>
Cc: Valerio Riedel <hvr@gnu.org>
Cc: "Luis R. Rodriguez" <mcgrof@ruslug.rutgers.edu>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201102112410.1049272-15-lee.jones@linaro.org
