- 24 Nov, 2020 24 commits
-
-
Sebastian Andrzej Siewior authored
ezusb_doicmd_wait() is invoked via ->init_cmd_wait() callback. This callback is only invoked hermesi_program_init() and hermesi_program_end() which are the ->program_init() and ->program_end() callbacks as assigned by `hermes_ops_local'. They are never used by the USB interface since the USB interface provides its own set of callbacks by `ezusb_ops'. Replace ezusb_doicmd_wait() with a warning in case I missed the obvious. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201113212252.2243570-9-bigeasy@linutronix.de
-
Sebastian Andrzej Siewior authored
All invocation of ezusb_write_ltv() happen via ->write_ltv() and are performed under the orinoco_lock() which disables BH. Use ezusb_req_ctx_wait_poll() for ezusb_write_ltv() because it must not sleep. Signed-off-by:
-
Sebastian Andrzej Siewior authored
ezusb_read_pda() is invoked via ->read_pda() while firmware is loaded in preemtible context. Use ezusb_req_ctx_wait_compl() in ezusb_read_pda(). Signed-off-by:
-
Sebastian Andrzej Siewior authored
The ezusb_program() is invoked via ->program() in preemptible context during firmware loading. This is also true for the ->program_init() and ->program_end() callback. Use ezusb_req_ctx_wait_compl() in ezusb_program_init(), ezusb_program_bytes(), ezusb_program_end() which are part of firmware loading during device probe. Signed-off-by:
-
Sebastian Andrzej Siewior authored
ezusb_init() is always invoked in preemptible context during device probe. Only orinoco_up() -> orinoco_reinit_firmware() may invoke the function from atomic context but this is never used for the USB interface. Use ezusb_req_ctx_wait_compl() for the ezusb_write_ltv() and ezusb_docmd_wait() invocations from within ezusb_init(). Preserve the generic versions which have still other user via the callback. Signed-off-by:
-
Sebastian Andrzej Siewior authored
ezusb_xmit() sets ->in_rid in its request which means it does not wait for an answer. Use the ezusb_req_ctx_wait_skip() to denote that an answer is not expected. Signed-off-by:
-
Sebastian Andrzej Siewior authored
ezusb_access_ltv() sends the prepared request to the USB device. Requests which have ->in_rid set expect an answer from the USB device and the function has to wait until the URB with the answer arrives. The function uses in_interrupt() to determine if it can simply sleep on the completion and be woken up once the answer arrives or if it needs to poll on the completion. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Aside of that in_interrupt() is not correct as it does not catch preempt disabled regions in which sleeping is also not allowed. Provide stubs which can be used as a replacement. The current default is the current behaviour which sleeps/polls depending on in_interrupt(). The goal is to audit all callers and use either the poll or sleep version. Signed-off-by:
-
Sebastian Andrzej Siewior authored
ezusb_xmit() allocates a context which is leaked if orinoco_process_xmit_skb() returns an error. Move ezusb_alloc_ctx() after the invocation of orinoco_process_xmit_skb() because the context is not needed so early. ezusb_access_ltv() will cleanup the context in case of an error. Fixes: bac6fafd ("orinoco: refactor xmit path") Signed-off-by:
-
Zhang Changzhong authored
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 3b1e0a7b ("brcmfmac: add support for SAE authentication offload") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by:
Chi-hsien Lin <chi-hsien.lin@infineon.com> Signed-off-by:
-
Yejune Deng authored
a set of atomic_inc() looks more readable Signed-off-by:
Yejune Deng <yejune.deng@gmail.com> Signed-off-by:
-
Brian Norris authored
It's much easier to spot what went wrong when you print out the unhandled key type. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Ching-Te Ku authored
Fix sometimes FW information will be parsed as wrong value, do a correction of sign bit to show the correct information. (Ex, Value should be 20, but it shows 236.) Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
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 authored
Remove some action which were writing scan bit to scoreboard, since these behaviors are redundant. It is already done in WLAN info notify. Signed-off-by:
-
Ching-Te Ku authored
Force set the coexistence to BT high priority during WLAN initial/power-on step. Since the duration the related setting may be not ready yet. The score board is not related to scan when initialing, remove the scan parameter. Signed-off-by:
-
Ching-Te Ku authored
While the mechanism goes to 2G_free_run or WL5G_BT2G, set BT to hardware PTA mode to get a more efficiently performance. Add a flag to indicate antenna switch is supported or not so that the IC serials which has different antenna structure can set antenna correctly. Signed-off-by:
-
Ching-Te Ku authored
The updated parameter and original parameter all means TDMA-OFF. The original setting write 0x8 to firmware, but it only works for some old IC series. To avoid the confusing, update a proper parameter. Signed-off-by:
-
Ching-Te Ku authored
Add the related coexistence mechanism about RF4CE and WLAN connected flag to decide control packet is whether higher or normal priority. Signed-off-by:
-
Ching-Te Ku authored
Because sometimes hardware action may be unpredictable. (Ex: after WLAN LPS...etc) Add a check mechanism if the action is triggered by some concerned case, it can force to write the table again. Signed-off-by:
-
Ching-Te Ku authored
When WLAN in critical procedure, such as connecting, scan and so on, coexistence will notify BT by scoreboard. While BT firmware received the scoreboard interrupt, it will adjust BT page priority lower to avoid WLAN critical procedure suffering impact. Signed-off-by:
-
Ching-Te Ku authored
Because the WLAN RSSI report feature had been implemented at WLAN link info update function, it is redundant to update WLAN RSSI while BT is updating link info, so remove the update WLAN RSSI part. Signed-off-by:
-
Ching-Te Ku authored
Add considering for different WLAN beacon interval in coexistence mechanism. Because the WLAN beacon period may be not 100 ms, so it's necessary to consider any beacon period and set timer according to the interval. Signed-off-by:
-
Ping-Ke Shih authored
In order to help debugging in field, we add some log messages. Signed-off-by:
-
Ping-Ke Shih authored
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:
-
- 10 Nov, 2020 16 commits
-
-
Ching-Te Ku authored
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 authored
Since coexistence issue is related to WL/BT and each digital/analog/rf, and these issues are often critical with low failure rate, add more debugging information is helpful to clarify issues. Signed-off-by:
-
Ching-Te Ku authored
Adaptive Frequency Hopping(AFH) is a method of transmitting radio signals by rapidly changing the carrier frequency among many distinct frequencies, which can avoid interference. Add this feature to update AFH parameter for 8822b. Signed-off-by:
-
Ching-Te Ku authored
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 authored
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 authored
The original stop_dm flag is shared with the wifi and coexistence mechanism internal usage, which represent two meanings, and makes developers hard to debug. Add a new flag manual_control for coexistence mechanism usage only. Signed-off-by:
-
Ching-Te Ku authored
To make sure the related ANT/RF_PARA setting will be expected result in COEX. Signed-off-by:
-
Ching-Te Ku authored
Adjust space and comments, and fix "line over 80 characters" warnings reported by checkpatch. Signed-off-by:
-
Ching-Te Ku authored
Use macro definition to replace magic number. Signed-off-by:
-
Ching-Te Ku authored
Update COEX parameters and logic to enhance WL/BT performance while WL_Busy + A2DP in a less interference environment. It can avoid the interference comes cross from each other and earned more performance. Signed-off-by:
-
Ching-Te Ku authored
Some register definition and bit definition were incorrect. e.g. REG_BT_COEX_V2 should be word alignment to meet the coding style. e.g. set REG_BT_TDMA_TIME[5:0]=0x5, But the original is to set REG_BT_TDMA_TIME[7:0]=0x5. This will cause unexpected hardware behavior. Signed-off-by:
-
Wang Qing authored
workarould -> workaround Signed-off-by:
Wang Qing <wangqing@vivo.com> Signed-off-by:
-
Marek Vasut authored
The inner do { ... } while loop is completely useless, all it does is iterate over a switch-case statement, one bit at a time. This can easily be replaced by simple if (status & bit) { ... } tests for each bit. No functional change. 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 Signed-off-by:
-
Marek Vasut authored
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:
Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by:
-
Tsuchiya Yuto authored
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:
-
Tsuchiya Yuto authored
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:
-
