* [PATCH v3 0/2] start recovery process when payload length overflow for sdio
@ 2019-12-31 9:28 ` Wen Gong
0 siblings, 0 replies; 8+ messages in thread
From: Wen Gong @ 2019-12-31 9:28 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
when it happened payload length exceeds max htc length, start recovery process
v3: change atomic_inc_and_test to atomic_add_return, remove check of ATH10K_STATE_ON
v2: add "add refcount for ath10k_core_restart" and remove ar_sdio->can_recovery
Wen Gong (2):
ath10k: add refcount for ath10k_core_restart
ath10k: start recovery process when payload length exceeds max htc
length for sdio
drivers/net/wireless/ath/ath10k/core.c | 8 ++++++++
drivers/net/wireless/ath/ath10k/core.h | 2 ++
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ath/ath10k/sdio.c | 4 ++++
4 files changed, 15 insertions(+)
--
2.23.0
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH v3 0/2] start recovery process when payload length overflow for sdio @ 2019-12-31 9:28 ` Wen Gong 0 siblings, 0 replies; 8+ messages in thread From: Wen Gong @ 2019-12-31 9:28 UTC (permalink / raw) To: ath10k; +Cc: linux-wireless when it happened payload length exceeds max htc length, start recovery process v3: change atomic_inc_and_test to atomic_add_return, remove check of ATH10K_STATE_ON v2: add "add refcount for ath10k_core_restart" and remove ar_sdio->can_recovery Wen Gong (2): ath10k: add refcount for ath10k_core_restart ath10k: start recovery process when payload length exceeds max htc length for sdio drivers/net/wireless/ath/ath10k/core.c | 8 ++++++++ drivers/net/wireless/ath/ath10k/core.h | 2 ++ drivers/net/wireless/ath/ath10k/mac.c | 1 + drivers/net/wireless/ath/ath10k/sdio.c | 4 ++++ 4 files changed, 15 insertions(+) -- 2.23.0 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v3 1/2] ath10k: add refcount for ath10k_core_restart 2019-12-31 9:28 ` Wen Gong @ 2019-12-31 9:28 ` Wen Gong -1 siblings, 0 replies; 8+ messages in thread From: Wen Gong @ 2019-12-31 9:28 UTC (permalink / raw) To: ath10k; +Cc: linux-wireless When it has more than one restart_work queued meanwhile, the 2nd restart_work is very esay to break the 1st restart work and lead recovery fail. Add a ref count to allow only one restart work running untill device successfully recovered. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong <wgong@codeaurora.org> --- drivers/net/wireless/ath/ath10k/core.c | 8 ++++++++ drivers/net/wireless/ath/ath10k/core.h | 2 ++ drivers/net/wireless/ath/ath10k/mac.c | 1 + 3 files changed, 11 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 91f131b87efc..9439e575ec63 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -2199,6 +2199,14 @@ static void ath10k_core_restart(struct work_struct *work) { struct ath10k *ar = container_of(work, struct ath10k, restart_work); int ret; + int restart_count; + + restart_count = atomic_add_return(1, &ar->restart_count); + if (restart_count > 1) { + ath10k_warn(ar, "can not restart, count: %d\n", restart_count); + atomic_dec(&ar->restart_count); + return; + } set_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags); diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index e57b2e7235e3..810c99f2dc0e 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -982,6 +982,8 @@ struct ath10k { /* protected by conf_mutex */ u8 ps_state_enable; + atomic_t restart_count; + bool nlo_enabled; bool p2p; diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 3856edba7915..bc1574145e66 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -7208,6 +7208,7 @@ static void ath10k_reconfig_complete(struct ieee80211_hw *hw, ath10k_info(ar, "device successfully recovered\n"); ar->state = ATH10K_STATE_ON; ieee80211_wake_queues(ar->hw); + atomic_dec(&ar->restart_count); } mutex_unlock(&ar->conf_mutex); -- 2.23.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v3 1/2] ath10k: add refcount for ath10k_core_restart @ 2019-12-31 9:28 ` Wen Gong 0 siblings, 0 replies; 8+ messages in thread From: Wen Gong @ 2019-12-31 9:28 UTC (permalink / raw) To: ath10k; +Cc: linux-wireless When it has more than one restart_work queued meanwhile, the 2nd restart_work is very esay to break the 1st restart work and lead recovery fail. Add a ref count to allow only one restart work running untill device successfully recovered. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong <wgong@codeaurora.org> --- drivers/net/wireless/ath/ath10k/core.c | 8 ++++++++ drivers/net/wireless/ath/ath10k/core.h | 2 ++ drivers/net/wireless/ath/ath10k/mac.c | 1 + 3 files changed, 11 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 91f131b87efc..9439e575ec63 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -2199,6 +2199,14 @@ static void ath10k_core_restart(struct work_struct *work) { struct ath10k *ar = container_of(work, struct ath10k, restart_work); int ret; + int restart_count; + + restart_count = atomic_add_return(1, &ar->restart_count); + if (restart_count > 1) { + ath10k_warn(ar, "can not restart, count: %d\n", restart_count); + atomic_dec(&ar->restart_count); + return; + } set_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags); diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index e57b2e7235e3..810c99f2dc0e 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -982,6 +982,8 @@ struct ath10k { /* protected by conf_mutex */ u8 ps_state_enable; + atomic_t restart_count; + bool nlo_enabled; bool p2p; diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 3856edba7915..bc1574145e66 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -7208,6 +7208,7 @@ static void ath10k_reconfig_complete(struct ieee80211_hw *hw, ath10k_info(ar, "device successfully recovered\n"); ar->state = ATH10K_STATE_ON; ieee80211_wake_queues(ar->hw); + atomic_dec(&ar->restart_count); } mutex_unlock(&ar->conf_mutex); -- 2.23.0 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v3 2/2] ath10k: start recovery process when payload length exceeds max htc length for sdio 2019-12-31 9:28 ` Wen Gong @ 2019-12-31 9:28 ` Wen Gong -1 siblings, 0 replies; 8+ messages in thread From: Wen Gong @ 2019-12-31 9:28 UTC (permalink / raw) To: ath10k; +Cc: linux-wireless When simulate random transfer fail for sdio write and read, it happened "payload length exceeds max htc length" and recovery later sometimes. Test steps: 1. Add config and update kernel: CONFIG_FAIL_MMC_REQUEST=y CONFIG_FAULT_INJECTION=y CONFIG_FAULT_INJECTION_DEBUG_FS=y 2. Run simulate fail: cd /sys/kernel/debug/mmc1/fail_mmc_request echo 10 > probability echo 10 > times # repeat until hitting issues 3. It happened payload length exceeds max htc length. [ 199.935506] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 .... [ 264.990191] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 4. after some time, such as 60 seconds, it start recovery which triggered by wmi command timeout for periodic scan. [ 269.229232] ieee80211 phy0: Hardware restart was requested [ 269.734693] ath10k_sdio mmc1:0001:1: device successfully recovered The simulate fail of sdio is not a real sdio transter fail, it only set an error status in mmc_should_fail_request after the transfer end, actually the transfer is success, then sdio_io_rw_ext_helper will return error status and stop transfer the left data. For example, the really RX len is 286 bytes, then it will split to 2 blocks in sdio_io_rw_ext_helper, one is 256 bytes, left is 30 bytes, if the first 256 bytes get an error status by mmc_should_fail_request,then the left 30 bytes will not read in this RX operation. Then when the next RX arrive, the left 30 bytes will be considered as the header of the read, the top 4 bytes of the 30 bytes will be considered as lookaheads, but actually the 4 bytes is not the lookaheads, so the len from this lookaheads is not correct, it exceeds max htc length 4088 sometimes. When happened exceeds, the buffer chain is not matched between firmware and ath10k, then it need to start recovery ASAP. Recently then recovery will be started by wmi command timeout, but it will be long time later, for example, it is 60+ seconds later from the periodic scan, if it does not have periodic scan, it will be longer. Start recovery when it happened "payload length exceeds max htc length" will be reasonable. This patch only effect sdio chips. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong <wgong@codeaurora.org> --- drivers/net/wireless/ath/ath10k/sdio.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c index 7b894dcaad2e..f48a56906f71 100644 --- a/drivers/net/wireless/ath/ath10k/sdio.c +++ b/drivers/net/wireless/ath/ath10k/sdio.c @@ -557,6 +557,10 @@ static int ath10k_sdio_mbox_rx_alloc(struct ath10k *ar, le16_to_cpu(htc_hdr->len), ATH10K_HTC_MBOX_MAX_PAYLOAD_LENGTH); ret = -ENOMEM; + + queue_work(ar->workqueue, &ar->restart_work); + ath10k_warn(ar, "exceeds length, start recovery\n"); + goto err; } -- 2.23.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v3 2/2] ath10k: start recovery process when payload length exceeds max htc length for sdio @ 2019-12-31 9:28 ` Wen Gong 0 siblings, 0 replies; 8+ messages in thread From: Wen Gong @ 2019-12-31 9:28 UTC (permalink / raw) To: ath10k; +Cc: linux-wireless When simulate random transfer fail for sdio write and read, it happened "payload length exceeds max htc length" and recovery later sometimes. Test steps: 1. Add config and update kernel: CONFIG_FAIL_MMC_REQUEST=y CONFIG_FAULT_INJECTION=y CONFIG_FAULT_INJECTION_DEBUG_FS=y 2. Run simulate fail: cd /sys/kernel/debug/mmc1/fail_mmc_request echo 10 > probability echo 10 > times # repeat until hitting issues 3. It happened payload length exceeds max htc length. [ 199.935506] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 .... [ 264.990191] ath10k_sdio mmc1:0001:1: payload length 57005 exceeds max htc length: 4088 4. after some time, such as 60 seconds, it start recovery which triggered by wmi command timeout for periodic scan. [ 269.229232] ieee80211 phy0: Hardware restart was requested [ 269.734693] ath10k_sdio mmc1:0001:1: device successfully recovered The simulate fail of sdio is not a real sdio transter fail, it only set an error status in mmc_should_fail_request after the transfer end, actually the transfer is success, then sdio_io_rw_ext_helper will return error status and stop transfer the left data. For example, the really RX len is 286 bytes, then it will split to 2 blocks in sdio_io_rw_ext_helper, one is 256 bytes, left is 30 bytes, if the first 256 bytes get an error status by mmc_should_fail_request,then the left 30 bytes will not read in this RX operation. Then when the next RX arrive, the left 30 bytes will be considered as the header of the read, the top 4 bytes of the 30 bytes will be considered as lookaheads, but actually the 4 bytes is not the lookaheads, so the len from this lookaheads is not correct, it exceeds max htc length 4088 sometimes. When happened exceeds, the buffer chain is not matched between firmware and ath10k, then it need to start recovery ASAP. Recently then recovery will be started by wmi command timeout, but it will be long time later, for example, it is 60+ seconds later from the periodic scan, if it does not have periodic scan, it will be longer. Start recovery when it happened "payload length exceeds max htc length" will be reasonable. This patch only effect sdio chips. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by: Wen Gong <wgong@codeaurora.org> --- drivers/net/wireless/ath/ath10k/sdio.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c index 7b894dcaad2e..f48a56906f71 100644 --- a/drivers/net/wireless/ath/ath10k/sdio.c +++ b/drivers/net/wireless/ath/ath10k/sdio.c @@ -557,6 +557,10 @@ static int ath10k_sdio_mbox_rx_alloc(struct ath10k *ar, le16_to_cpu(htc_hdr->len), ATH10K_HTC_MBOX_MAX_PAYLOAD_LENGTH); ret = -ENOMEM; + + queue_work(ar->workqueue, &ar->restart_work); + ath10k_warn(ar, "exceeds length, start recovery\n"); + goto err; } -- 2.23.0 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 8+ messages in thread
* RE: [PATCH v3 0/2] start recovery process when payload length overflow for sdio 2019-12-31 9:28 ` Wen Gong @ 2020-01-08 3:23 ` Wen Gong -1 siblings, 0 replies; 8+ messages in thread From: Wen Gong @ 2020-01-08 3:23 UTC (permalink / raw) To: Wen Gong, ath10k; +Cc: linux-wireless > -----Original Message----- > From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong > Sent: Tuesday, December 31, 2019 5:28 PM > To: ath10k@lists.infradead.org > Cc: linux-wireless@vger.kernel.org > Subject: [EXT] [PATCH v3 0/2] start recovery process when payload length > overflow for sdio > V4 sent: https://patchwork.kernel.org/cover/11322579/ https://patchwork.kernel.org/patch/11322581/ https://patchwork.kernel.org/patch/11322583/ > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH v3 0/2] start recovery process when payload length overflow for sdio @ 2020-01-08 3:23 ` Wen Gong 0 siblings, 0 replies; 8+ messages in thread From: Wen Gong @ 2020-01-08 3:23 UTC (permalink / raw) To: Wen Gong, ath10k; +Cc: linux-wireless > -----Original Message----- > From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong > Sent: Tuesday, December 31, 2019 5:28 PM > To: ath10k@lists.infradead.org > Cc: linux-wireless@vger.kernel.org > Subject: [EXT] [PATCH v3 0/2] start recovery process when payload length > overflow for sdio > V4 sent: https://patchwork.kernel.org/cover/11322579/ https://patchwork.kernel.org/patch/11322581/ https://patchwork.kernel.org/patch/11322583/ > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-01-08 3:24 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-31 9:28 [PATCH v3 0/2] start recovery process when payload length overflow for sdio Wen Gong 2019-12-31 9:28 ` Wen Gong 2019-12-31 9:28 ` [PATCH v3 1/2] ath10k: add refcount for ath10k_core_restart Wen Gong 2019-12-31 9:28 ` Wen Gong 2019-12-31 9:28 ` [PATCH v3 2/2] ath10k: start recovery process when payload length exceeds max htc length for sdio Wen Gong 2019-12-31 9:28 ` Wen Gong 2020-01-08 3:23 ` [PATCH v3 0/2] start recovery process when payload length overflow " Wen Gong 2020-01-08 3:23 ` Wen Gong
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.